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