SPDIF/AES input sample rate handling?

SPDIF/AES input sample rate handling?

[Robert Hancock]

A question about how ALSA drivers should handle SPDIF or AES digital 
audio inputs: I may be eventually be writing an ALSA driver for an audio 
card which has multiple AES digital audio inputs. The card would support 
multiple sample rates on input with the provided input data being fed 
directly to software with no sample rate conversion. This raises the 
question of how to handle requests for a particular sample rate. If the 
user app requests recording at a sample rate of say 32KHz and we say 
"OK", and then they proceed to connect an input running at 44.1KHz 
sampling rate, the card will produce and the app will receive samples at 
a faster than expected rate. Presumably this is something the app just 
has to deal with, but will anything in the ALSA core/library puke 
because of it?

Or is there a better way to deal with this kind of situation?

Re: SPDIF/AES input sample rate handling?

[Eliot Blennerhassett]

Robert Hancock wrote:
> A question about how ALSA drivers should handle SPDIF or AES digital 
> audio inputs: I may be eventually be writing an ALSA driver for an audio 
> card which has multiple AES digital audio inputs. The card would support 
> multiple sample rates on input with the provided input data being fed 
> directly to software with no sample rate conversion. This raises the 
> question of how to handle requests for a particular sample rate. If the 
> user app requests recording at a sample rate of say 32KHz and we say 
> "OK", and then they proceed to connect an input running at 44.1KHz 
> sampling rate, the card will produce and the app will receive samples at 
> a faster than expected rate. Presumably this is something the app just 
> has to deal with, but will anything in the ALSA core/library puke 
> because of it?

I think it will just run faster.

If you *already* have the 44.1kHz input connected when the app tries to
set up the stream, then your driver can report that it is only capable
of 44.1, and the app or ALSA plug layer will be forced to do resampling.

aside: does it make sense to allow recording at all if there is no valid
input clock?

I'm not sure of the best way to dynamically change such a constraint
when the input changes.

--
Eliot