Digital sound card conventions

Digital sound card conventions

[Anders Torger]

I'm doing a maintenance update on the rme96 driver, and I wonder if 
there are any conventions to follow in the driver concerning digital 
sound cards.

The specific questions are how to handle sample rates and sound formats 
on the input.

The sound card supports several sample rates and formats. What should 
happen if the user tries to open the input with 48000 kHz ADAT, but the 
format is actually 44100 kHz and SPDIF? I can allow it if I want to, 
the user will get data, but at 48000 kHz of course.

What should happen when there is no input signal at all? The hardware 
supports opening the input, but should I do so in the driver?

The signal can of course change in runtime as well...

I'm thinking of allowing it all, but I don't know if that is the right 
way to go.

/Anders Torger


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Digital sound card conventions

[Jaroslav Kysela]

On Fri, 3 Jan 2003, Anders Torger wrote:

> I'm doing a maintenance update on the rme96 driver, and I wonder if 
> there are any conventions to follow in the driver concerning digital 
> sound cards.
> 
> The specific questions are how to handle sample rates and sound formats 
> on the input.
> 
> The sound card supports several sample rates and formats. What should 
> happen if the user tries to open the input with 48000 kHz ADAT, but the 
> format is actually 44100 kHz and SPDIF? I can allow it if I want to, 
> the user will get data, but at 48000 kHz of course.
> 
> What should happen when there is no input signal at all? The hardware 
> supports opening the input, but should I do so in the driver?
> 
> The signal can of course change in runtime as well...
> 
> I'm thinking of allowing it all, but I don't know if that is the right 
> way to go.

This part of PCM API has not been discussed. I think that we should follow
the most easy way: It is - allow only sample rate given by application, if
the master clock is using another sample rate - in trigger() callback -
driver will fail. Also it will fail, when sample rate is changed during
operation. We probably need to add a new PCM state -
SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative for
applications). The notification of master clock / sample rate (or other
parameter) changes should be implemented using the control API.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Anders Torger]

On Friday 03 January 2003 21.33, Jaroslav Kysela wrote:
> On Fri, 3 Jan 2003, Anders Torger wrote:
> > I'm doing a maintenance update on the rme96 driver, and I wonder if
> > there are any conventions to follow in the driver concerning
> > digital sound cards.
> >
> > The specific questions are how to handle sample rates and sound
> > formats on the input.
> >
> > The sound card supports several sample rates and formats. What
> > should happen if the user tries to open the input with 48000 kHz
> > ADAT, but the format is actually 44100 kHz and SPDIF? I can allow
> > it if I want to, the user will get data, but at 48000 kHz of
> > course.
> >
> > What should happen when there is no input signal at all? The
> > hardware supports opening the input, but should I do so in the
> > driver?
> >
> > The signal can of course change in runtime as well...
> >
> > I'm thinking of allowing it all, but I don't know if that is the
> > right way to go.
>
> This part of PCM API has not been discussed. I think that we should
> follow the most easy way: It is - allow only sample rate given by
> application, if the master clock is using another sample rate - in
> trigger() callback - driver will fail. Also it will fail, when sample
> rate is changed during operation. We probably need to add a new PCM
> state -
> SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative
> for applications). The notification of master clock / sample rate (or
> other parameter) changes should be implemented using the control API.

So what you are saying is, for now, do what is correct at the moment. Is 
this ok:

If no signal on the input - allow to open with any setting the hardware 
supports. The current rme96 driver will return -EIO, but that sucks if 
you're just opening the card to check some parameters, so I plan to 
change that.

If there is a signal on the input, limit the reported sound card 
capabilities to only those currently available on the input, so when 
the sound card is opened for capture, it seems only capable of 48kHz if 
that is the current sample rate.

/Anders Torger


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Paul Davis]

>
>This part of PCM API has not been discussed. I think that we should follow
>the most easy way: It is - allow only sample rate given by application, if
>the master clock is using another sample rate - in trigger() callback -
>driver will fail. 

this seems wrong to me. what should fail is an attempt to set the
sample rate unless the hardware is its own clock Master. if no attempt
is made to set it, then the application gets whatever the hardware is
running at, whether that is externally controlled or some h/w specific
default. 

>		   Also it will fail, when sample rate is changed during
>operation. 

the hammerfall driver used to contain stubs for doing this. every
read/write operation would check that the (possibly externally
controlled) SR was the same as "last time". i never did any more on this.

>	    We probably need to add a new PCM state -
>SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative for
>applications). The notification of master clock / sample rate (or other
>parameter) changes should be implemented using the control API.

and already is for some cards (and some parameters).

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Anders Torger]

On Friday 03 January 2003 22.47, Paul Davis wrote:
> >This part of PCM API has not been discussed. I think that we should
> > follow the most easy way: It is - allow only sample rate given by
> > application, if the master clock is using another sample rate - in
> > trigger() callback - driver will fail.
>
> this seems wrong to me. what should fail is an attempt to set the
> sample rate unless the hardware is its own clock Master. if no
> attempt is made to set it, then the application gets whatever the
> hardware is running at, whether that is externally controlled or some
> h/w specific default.

An attempt to set it to the sample rate that happens be the correct one 
should be ok, at least I think so.

So, your suggestion is, that for capture, always state the full hardware 
capability (in hwparams), but fail if incorrect the settings are made? 
I think that is ok too, but currently I'm narrowing down the hwparams 
to fit what is available at the input when the sound card is opened (of 
course, that could have changed until the sound card is started, but it 
is quite unlikely).

I think both approaches are ok, but narrowing down the alternatives I 
think is more nice to the applications. My guess is that the common use 
of a digital sound card is that the input signal is not changed too 
often, and then it is nice if the software gets the correct 
capabilities, so those applications that think that all sound cards are 
analog will work in the expected way anyway.

> >		   Also it will fail, when sample rate is changed during
> >operation.
>
> the hammerfall driver used to contain stubs for doing this. every
> read/write operation would check that the (possibly externally
> controlled) SR was the same as "last time". i never did any more on
> this.

Uhmm... I don't think I will include changed sample rate / format 
callback stuff for now, because I don't know how to implement it. 
However, if there is a good example which I could imitate, let me know.

/Anders Torger


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Jaroslav Kysela]

On Fri, 3 Jan 2003, Paul Davis wrote:

> >This part of PCM API has not been discussed. I think that we should follow
> >the most easy way: It is - allow only sample rate given by application, if
> >the master clock is using another sample rate - in trigger() callback -
> >driver will fail. 
> 
> this seems wrong to me. what should fail is an attempt to set the
> sample rate unless the hardware is its own clock Master. if no attempt
> is made to set it, then the application gets whatever the hardware is
> running at, whether that is externally controlled or some h/w specific
> default. 

I think that it's wrong when application receives stream with another
parameters than requested. Imagine that you're doing a software sample
rate conversion and we really need to know the exact rate for this job.

So my suggestion is:

1) offer all available sample rates in open() or reduce them as suggested
   by Anders
2) in trigger(START)
   - check if current sample rate match with hw_params - if not - fail
3) in interrupt callback
   - same job as trigger does

Note that we have to implement this algorithm also for playback, because 
it can use external timing as well.

> >		   Also it will fail, when sample rate is changed during
> >operation. 
> 
> the hammerfall driver used to contain stubs for doing this. every
> read/write operation would check that the (possibly externally
> controlled) SR was the same as "last time". i never did any more on this.
> 
> >	    We probably need to add a new PCM state -
> >SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative for
> >applications). The notification of master clock / sample rate (or other
> >parameter) changes should be implemented using the control API.
> 
> and already is for some cards (and some parameters).

Yes, I know.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Paul Davis]

>> this seems wrong to me. what should fail is an attempt to set the
>> sample rate unless the hardware is its own clock Master. if no attempt
>> is made to set it, then the application gets whatever the hardware is
>> running at, whether that is externally controlled or some h/w specific
>> default. 
>
>I think that it's wrong when application receives stream with another
>parameters than requested. 

how would that happen?

if it asks for a specific rate via hw_params, it will either get it,
or fail.  if it doesn't ask for a specific rate, it will get whatever
the h/w is using (some default and/or the value set by an external clock).

>			    Imagine that you're doing a software sample
>rate conversion and we really need to know the exact rate for this job.

you can get it by just asking the device what rate its using, or by
knowing that your hw_params request completed successfully.

>1) offer all available sample rates in open() or reduce them as suggested
>   by Anders
>2) in trigger(START)
>   - check if current sample rate match with hw_params - if not - fail
>3) in interrupt callback
>   - same job as trigger does

what about checking in read/write operations, in case the external
clock has changed?

--p




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Jaroslav Kysela]

On Mon, 6 Jan 2003, Paul Davis wrote:

> >> this seems wrong to me. what should fail is an attempt to set the
> >> sample rate unless the hardware is its own clock Master. if no attempt
> >> is made to set it, then the application gets whatever the hardware is
> >> running at, whether that is externally controlled or some h/w specific
> >> default. 
> >
> >I think that it's wrong when application receives stream with another
> >parameters than requested. 
> 
> how would that happen?
> 
> if it asks for a specific rate via hw_params, it will either get it,
> or fail.  if it doesn't ask for a specific rate, it will get whatever
> the h/w is using (some default and/or the value set by an external clock).
> 
> >			    Imagine that you're doing a software sample
> >rate conversion and we really need to know the exact rate for this job.
> 
> you can get it by just asking the device what rate its using, or by
> knowing that your hw_params request completed successfully.

Ok, we speak about same things. It's ok when hw_params request returns an 
error code when rate doesn't match.

> >1) offer all available sample rates in open() or reduce them as suggested
> >   by Anders
> >2) in trigger(START)
> >   - check if current sample rate match with hw_params - if not - fail
> >3) in interrupt callback
> >   - same job as trigger does
> 
> what about checking in read/write operations, in case the external
> clock has changed?

Yes, the check might be in copy/silence/pointer callbacks, too.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Digital sound card conventions

[Takashi Iwai]

At Mon, 06 Jan 2003 11:28:41 -0500,
Paul Davis wrote:
> 
> >1) offer all available sample rates in open() or reduce them as suggested
> >   by Anders
> >2) in trigger(START)
> >   - check if current sample rate match with hw_params - if not - fail
> >3) in interrupt callback
> >   - same job as trigger does
> 
> what about checking in read/write operations, in case the external
> clock has changed?

iiuc, read/write are not called when the buffer is mmapped, so this
might not work in every case...

if interrupts are really generated, we can send some notification in
the interrupt handler (just like snd_ctl_notify() does), and check it
in the next (or sleeping) read/write/poll operation.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com