Mixer & ac97.so problems

QNX Newsgroups (Archives) qdn.public.ddk.audio
1

It appears that ac97.so creates mixer elements in such a way that
different inputs can not be used simultaneously. The mixer application
only allows to ‘Select’ one of inputs at a time. Individual volume
controls are not available either so in fact you can’t really mix
anything with the mixer.

Is that proper behavior? I noticed that Solo1 driver (which has its own
mixer code) does something different - when you run the mixer there are
no ‘select’ radiobuttons and there are individual volume controls. One
can actually record signals from multiple sources with Solo1. I used to
think Solo1 is rather primitive chip, how come AC97 codecs can’t do
that?

I also found that Windows allows you to record from multiple sources, at
least on SBLive (which has AC97 codec). I could not do it using default
Windows Sound Recorder, but Creative Labs recorder (which also allows to
select only one input at a time) has ‘What You Hear’ input among the
choices. That will record all unmuted channels. Windows mixer does not
have concept of ‘Selection’ of input sources at all, in fact it treats
capture just like playback - there are no separate items for capture.
And you can use volume controls during capture.

That makes me think Windows has different routing scheme for AC97
codecs. They probably route Mic/Line/Aux/Whatever inputs into
multiplexor after they pass volume/mute elements. Looking at
‘simplified codec scheme’ in the audio DDK docs it appears QNX routes
them into mutliplexor before those controls. If ac97.so does the same
thing, it would explain why there’s no volume/mute controls. It still
would not explain why inputs can’t be all selected together, they are
all end up in multiplexor anyway don’t they?

May be it is just mixer bug? If not, I would suggest to change ac97.so.
As of now it makes really pathetic ‘mixer’.

Some related questions:

  1. What is ‘Stereo Mix’ input (available for ac97-based mixers)? It
    appears to pass LineIn, but not Mic. I was hoping it is same thing as
    ‘What You Hear’…

  2. What is meaning of subchannel mixers on capture channels (if any)?
    The phrecord does no have input gain/mute controls, when a ‘volume/mute’
    functions would be called?

  3. I’d appreciate better explanation of SRC_test/SRC_set functions. Docs
    say driver must call them to make use of them, but then why are they
    part of mixer parameters? When they are needed? Are they related to
    S/PDIF support? Docs mention that DDK does address S/PDIF support but no
    word beyond that statement…

  • igor
2

I really don’t like to be annoying but silence is frustrating. I
understand we can’t expect really fast answers these days, but this
group does not appear to be overloaded with questions. Answering one
question per day would not be too much of efforts, would it? How about
one per 2 days? I would think those particular questions do not require
any time-consuming investigations, do they?

regards,

  • igor

Igor Kovalenko wrote:

It appears that ac97.so creates mixer elements in such a way that
different inputs can not be used simultaneously. The mixer application
only allows to ‘Select’ one of inputs at a time. Individual volume
controls are not available either so in fact you can’t really mix
anything with the mixer.

Is that proper behavior? I noticed that Solo1 driver (which has its own
mixer code) does something different - when you run the mixer there are
no ‘select’ radiobuttons and there are individual volume controls. One
can actually record signals from multiple sources with Solo1. I used to
think Solo1 is rather primitive chip, how come AC97 codecs can’t do
that?

I also found that Windows allows you to record from multiple sources, at
least on SBLive (which has AC97 codec). I could not do it using default
Windows Sound Recorder, but Creative Labs recorder (which also allows to
select only one input at a time) has ‘What You Hear’ input among the
choices. That will record all unmuted channels. Windows mixer does not
have concept of ‘Selection’ of input sources at all, in fact it treats
capture just like playback - there are no separate items for capture.
And you can use volume controls during capture.

That makes me think Windows has different routing scheme for AC97
codecs. They probably route Mic/Line/Aux/Whatever inputs into
multiplexor after they pass volume/mute elements. Looking at
‘simplified codec scheme’ in the audio DDK docs it appears QNX routes
them into mutliplexor before those controls. If ac97.so does the same
thing, it would explain why there’s no volume/mute controls. It still
would not explain why inputs can’t be all selected together, they are
all end up in multiplexor anyway don’t they?

May be it is just mixer bug? If not, I would suggest to change ac97.so.
As of now it makes really pathetic ‘mixer’.

Some related questions:

  1. What is ‘Stereo Mix’ input (available for ac97-based mixers)? It
    appears to pass LineIn, but not Mic. I was hoping it is same thing as
    ‘What You Hear’…

  2. What is meaning of subchannel mixers on capture channels (if any)?
    The phrecord does no have input gain/mute controls, when a ‘volume/mute’
    functions would be called?

  3. I’d appreciate better explanation of SRC_test/SRC_set functions. Docs
    say driver must call them to make use of them, but then why are they
    part of mixer parameters? When they are needed? Are they related to
    S/PDIF support? Docs mention that DDK does address S/PDIF support but no
    word beyond that statement…

  • igor
3

It appears that ac97.so creates mixer elements in such a way that
different inputs can not be used simultaneously. The mixer application
only allows to ‘Select’ one of inputs at a time. Individual volume
controls are not available either so in fact you can’t really mix
anything with the mixer.

Is that proper behavior? I noticed that Solo1 driver (which has its own
mixer code) does something different - when you run the mixer there are
no ‘select’ radiobuttons and there are individual volume controls. One
can actually record signals from multiple sources with Solo1. I used to
think Solo1 is rather primitive chip, how come AC97 codecs can’t do
that?

If you look at the AC’97 specification, the input to the ADC
is controlled by a mux while the Solo1 mixer uses a switch
on every input.

Some related questions:

  1. What is ‘Stereo Mix’ input (available for ac97-based mixers)? It
    appears to pass LineIn, but not Mic. I was hoping it is same thing as
    ‘What You Hear’…

It is, the “Stereo Mix” is all the sound at the output
connector (speakers) routed back to the ADC. Or as the AC’97
spec calls it “what you hear is what you get” (WYHIWYG)

  1. What is meaning of subchannel mixers on capture channels (if any)?
    The phrecord does no have input gain/mute controls, when a ‘volume/mute’
    functions would be called?

Exactly the same as for a playback channel. If a subchannel
group is availiable it would affect only that stream. So if
we have a card that allows 2 simultaneous capture channels
with subchannel mixers, one stream’s volume can be adjusted
without affecting the other.

  1. I’d appreciate better explanation of SRC_test/SRC_set functions. Docs
    say driver must call them to make use of them, but then why are they
    part of mixer parameters? When they are needed? Are they related to
    S/PDIF support? Docs mention that DDK does address S/PDIF support but no
    word beyond that statement…

The AC’97 2.0 Variable Sample Rate Extension allows the
codec to do Sample Rate Conversion (SRC) providded the codec and
the controller chip support the spec.

The SRC_test function tests the codec to see if it will
support Variable Sample Rates and adjusts the pcm
capabilities structure accordingly.

The SRC_set function sets the rate converstion, and is
called when the channel is aquired.

4

audio_support wrote:

Some related questions:

  1. What is ‘Stereo Mix’ input (available for ac97-based mixers)? It
    appears to pass LineIn, but not Mic. I was hoping it is same thing as
    ‘What You Hear’…

It is, the “Stereo Mix” is all the sound at the output
connector (speakers) routed back to the ADC. Or as the AC’97
spec calls it “what you hear is what you get” (WYHIWYG)

Then why i can’t get Mic input when ‘Stereo Mix’ is selected? As I said,
Line-In works that way, but not Mic… Is that a bug or do I miss
something?

  1. What is meaning of subchannel mixers on capture channels (if any)?
    The phrecord does no have input gain/mute controls, when a ‘volume/mute’
    functions would be called?

Exactly the same as for a playback channel. If a subchannel
group is availiable it would affect only that stream. So if
we have a card that allows 2 simultaneous capture channels
with subchannel mixers, one stream’s volume can be adjusted
without affecting the other.

Adjusted using what? There’s no input gain control in phrecord. So how
does one ‘adjust’ them? Is that just phrecord limitation?

  1. I’d appreciate better explanation of SRC_test/SRC_set functions. Docs
    say driver must call them to make use of them, but then why are they
    part of mixer parameters? When they are needed? Are they related to
    S/PDIF support? Docs mention that DDK does address S/PDIF support but no
    word beyond that statement…

The AC’97 2.0 Variable Sample Rate Extension allows the
codec to do Sample Rate Conversion (SRC) providded the codec and
the controller chip support the spec.

The SRC_test function tests the codec to see if it will
support Variable Sample Rates and adjusts the pcm
capabilities structure accordingly.

The SRC_set function sets the rate converstion, and is
called when the channel is aquired.

How that is ‘variable’? The rate conversion is set when channel is
acquired in any case, isn’t it?

The question about S/PDIF remains unanswered. It appears new AC97 2.1
spec also addresses S/PDIF somehow…

Two other things:

  1. The mute_set() function appears to be always called with ‘mute’
    parameter being 0 (no matter if I am ‘muting’ or ‘unmuting’ a
    subchannel. Even weirder, the ‘mute’ button in phplay appear to work
    regardless of that and actually regardless of what mute_set() is doing
    at all.

  2. The DLL used to play WAV files implies that driver supports
    subchannel mixers. If driver does not create them using hardware and
    does not do ‘software emulation’ either, WAV playback using shipped QNX
    utils fails with ‘unable to init audio device’, but MP3 playback works.

  • igor
5

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

audio_support wrote:

Some related questions:

  1. What is ‘Stereo Mix’ input (available for ac97-based mixers)? It
    appears to pass LineIn, but not Mic. I was hoping it is same thing as
    ‘What You Hear’…

It is, the “Stereo Mix” is all the sound at the output
connector (speakers) routed back to the ADC. Or as the AC’97
spec calls it “what you hear is what you get” (WYHIWYG)


Then why i can’t get Mic input when ‘Stereo Mix’ is selected? As I said,
Line-In works that way, but not Mic… Is that a bug or do I miss
something?

I works fine here! Everything I can hear out the speakers is
recorded using the “Stereo Mix” input selection. You have to
unmute all the signals including mic (this can cause
feedback if the gain to too high). Rememeber Stereo mix will
ONLY record what you are hearing!

  1. What is meaning of subchannel mixers on capture channels (if any)?
    The phrecord does no have input gain/mute controls, when a ‘volume/mute’
    functions would be called?

Exactly the same as for a playback channel. If a subchannel
group is availiable it would affect only that stream. So if
we have a card that allows 2 simultaneous capture channels
with subchannel mixers, one stream’s volume can be adjusted
without affecting the other.

Adjusted using what? There’s no input gain control in phrecord. So how
does one ‘adjust’ them? Is that just phrecord limitation?

Just because phrecord doesn’t show a gain control doesn’t
mean that one does not exist. The API can return the mixer
group name that best controls the capture stream. In most
cards this group would use the mute and gain controls in the
AC97, but in high end cards the group could be made up of
subchannel controls.

Subchannel mixers are just mixer controls that exclusively
control their subchannel. As an example when using phplay to
play a wave (on audiopci & ac’97 codec) it’s volume slider
could adjust the "master’, “pcm” or subchannel group. But
using any group other then the subchannel group leads to
side effects when two playbacks are running at once.

Consider a system where a cd is playing and two phplay are
playing mp3’s.

If phplay’s slider was connect to the master group,
increasing it would cause the signals from the cd and both
phplays to get louder.

If phplay’s slider was connect to the pcm group, increasing
it would cause both phplays to get louder but not the cd.

If phplay’s slider was connect to the subchannel group,
increasing it only make that signal get louder and not the
others.

  1. I’d appreciate better explanation of SRC_test/SRC_set functions. Docs
    say driver must call them to make use of them, but then why are they
    part of mixer parameters? When they are needed? Are they related to
    S/PDIF support? Docs mention that DDK does address S/PDIF support but no
    word beyond that statement…

The AC’97 2.0 Variable Sample Rate Extension allows the
codec to do Sample Rate Conversion (SRC) providded the codec and
the controller chip support the spec.

The SRC_test function tests the codec to see if it will
support Variable Sample Rates and adjusts the pcm
capabilities structure accordingly.

The SRC_set function sets the rate converstion, and is
called when the channel is aquired.

How that is ‘variable’? The rate conversion is set when channel is
acquired in any case, isn’t it?

The original AC’97 spec said the codec supported a data of
48Khz only. AC’97 2.0 added the “Variable Sample Rate
Extension” that allows other rates. Why they used the word
‘variable’ I don’t know ask Intel. And yes the rate is set
during the aquire and is not changed.

The question about S/PDIF remains unanswered. It appears new AC97 2.1
spec also addresses S/PDIF somehow…

The AC’97 Rev 2.2 starts to address SPDIF but also recomends
using USB be used instead. Supporting SPDIF seems to be very
driver/hw specific and as such the DDK does not address it
directly nor does the AC97 dll have functionality for it.

But the driver has access to all codec registers and can
therefore support whatever it likes. Supporting PCM over
SPDIF is fairly straight forward, while supporting AC3 over
SPDIF is harder.

Two other things:

  1. The mute_set() function appears to be always called with ‘mute’
    parameter being 0 (no matter if I am ‘muting’ or ‘unmuting’ a
    subchannel. Even weirder, the ‘mute’ button in phplay appear to work
    regardless of that and actually regardless of what mute_set() is doing
    at all.

Phplay does some stange things, it uses a technique where to
mute a signal it moves it’s gain to 0 and never uses the hw
mute. This may explain what your seeing. When writing an
application we recommend using the hardware mute instead,
whenever possible.


  1. The DLL used to play WAV files implies that driver supports
    subchannel mixers. If driver does not create them using hardware and
    does not do ‘software emulation’ either, WAV playback using shipped QNX
    utils fails with ‘unable to init audio device’, but MP3 playback works.

Which DLL?

The API returns the “BEST” mixer group for the stream , that
may or may not be a subchannel group depending on what the
driver supports. The the case of Audiopci+AC’97 that group
would be the 'PCM" group of the mixer because no subchannel
group exsists.

6

Audio Support wrote:

I works fine here! Everything I can hear out the speakers is
recorded using the “Stereo Mix” input selection. You have to
unmute all the signals including mic (this can cause
feedback if the gain to too high). Rememeber Stereo mix will
ONLY record what you are hearing!

Weird… of course i understand those things and yet it doesn’t work for
me.
May be my codec is broken - it is the notorious Asahi Kasei 4540. Here
is piece of code which I picked up from QNX port of ALSA 0.5
(ftp.qnx.com):

/*

  • I/O routines, filter some registers for buggy codecs
    */
    static int snd_ac97_valid_reg(ac97_t ac97, unsigned short reg)
    {
    switch (ac97->id) {
    case 0x414B4D00: /     AK4540 /
    if (reg <= 0x1c || reg == 0x20 || reg == 0x26 || reg >= 0x7c)
    return 1;
    return 0;
    case 0x41445303: /     AD1819 /
    case 0x41445340: /     AD1881 /
    case 0x41445348: /     AD1885? */
    if (reg >= 0x3a && reg <= 0x59)
    return 0;
    return 1;
    }
    return 1;
    }

I am lucky enough to actually have codec with id 0x414B4D00. I can tell
you, it does not like accessing register 0x04 too. And I don’t think
that filtering code is in ac97.so now. I had to filter in
codec_read/codec_write funcs, otherwise codec just hangs when ac97.so
touches registers 0x04 or 0x28.
This is very messy and I think it should better be in ac97.so otherwise
many people may suffer and will have to find this out a hard way (like I
did). Or at least make a note in the ac97.so docs (which does not exist
yet).

Just because phrecord doesn’t show a gain control doesn’t
mean that one does not exist. The API can return the mixer

That’s what i wanted to know.

The original AC’97 spec said the codec supported a data of
48Khz only. AC’97 2.0 added the “Variable Sample Rate
Extension” that allows other rates. Why they used the word
‘variable’ I don’t know ask Intel. And yes the rate is set
during the aquire and is not changed.

Does it mean that driver can just set rate on codec to match rate of
stream, instead of passing PCM through source rate converter? The
maestro-2 driver does that (passing through SRC), at least for capture
channels. How to find out if a codec does support ‘variable’ rate or
not?

The question about S/PDIF remains unanswered. It appears new AC97 2.1
spec also addresses S/PDIF somehow…

The AC’97 Rev 2.2 starts to address SPDIF but also recomends
using USB be used instead.

What, Intel expects home audio systems to have USB jacks?

Supporting SPDIF seems to be very
driver/hw specific and as such the DDK does not address it
directly nor does the AC97 dll have functionality for it.

Have you noticed that 0.9beta release of ALSA claims ‘Uniform support
for S/PDIF and subchannel mixers’? I haven’t been able to figure code
behind that claim yet, but I haven’t tried hard :wink:

But the driver has access to all codec registers and can
therefore support whatever it likes. Supporting PCM over
SPDIF is fairly straight forward, while supporting AC3 over
SPDIF is harder.

It is really lacking part of DDK, especially given the claim in the docs
that it does address S/PDIF. Some explanations in docs and an example
would not hurt.

Audio API docs also say other funny things, like ‘we had to move to ALSA
0.5 from 0.2 because 0.2 primitive midi & sequencer support …’. It is
funny because then you read in Audio DDK that midi & sequencer are not
supported at all :wink:

Phplay does some stange things, it uses a technique where to
mute a signal it moves it’s gain to 0 and never uses the hw
mute. This may explain what your seeing. When writing an
application we recommend using the hardware mute instead,
whenever possible.

Ah, I see. I’d think drivers may do that trick when there’s no hadware
mute bit, but phplay … :wink:

  1. The DLL used to play WAV files implies that driver supports
    subchannel mixers. If driver does not create them using hardware and
    does not do ‘software emulation’ either, WAV playback using shipped QNX
    utils fails with ‘unable to init audio device’, but MP3 playback works.

Which DLL?

The API returns the “BEST” mixer group for the stream , that
may or may not be a subchannel group depending on what the
driver supports. The the case of Audiopci+AC’97 that group
would be the 'PCM" group of the mixer because no subchannel
group exsists.

I guess it is soundfile_noph.so, but you should know better what is used
to play WAV files. All drivers shipped with DDK call ado_pcm_sw_mix()
which I understand emulates subchannel groups. What I am saying is, if
you remove that call (and there’s no hardware subchannels), phplay will
play MP3 songs, but WAV will fail. I’d consider that a bug.

  • igor