[alsa-devel] Does ASoC support sound card with multiple interfaces?
Hi, I have a codec with multiple TX and RX channels. In ASoC tree, I have seen examples where these kind of codecs are implemented as multichannel codecs. Instead I want it to be treated as card with multiple interfaces, e.g. Instead of one interface with eight TX channels, I need it to behave it as card with four stereo playback interfaces. The primary aim for doing this is that multiple applications should be able to play/record simultaneously. AFAIK, In case of a multichannel card, if it is opened by one application for stereo playback, there is no way to use rest of the unused channels by other applications.
Is it easily possible to achieve what I am trying to? Any pointers to example driver source will greatly help!
BTW all three i.e., platform, machine as well as codec driver are to be implemented. I am aware of the fact that this requirement may affect all three.
Thanks in advance,
-- Ashish || GNU FAN ||
On Mon, Jan 02, 2012 at 08:36:13PM +0530, Ashish Chavan wrote:
Always CC maintainers!
I have a codec with multiple TX and RX channels. In ASoC tree, I have seen examples where these kind of codecs are implemented as multichannel codecs. Instead I want it to be treated as card with multiple
Yes, this is totally supported. There are quite a few examples of this in the tree. Your CODEC driver should just implement one DAI per audio interface.
I have a codec with multiple TX and RX channels. In ASoC tree, I have seen examples where these kind of codecs are implemented as multichannel codecs. Instead I want it to be treated as card with multiple
Yes, this is totally supported. There are quite a few examples of this in the tree. Your CODEC driver should just implement one DAI per audio interface.
Thanks.
I am looking at some of the examples in the tree and have a small query. I want to know how alsa-utils (aplay, arecord) will behave when a codec driver supports multiple DAIs. For example, let's assume that a codec driver implements two DAIs, both capable of doing stereo playback. Then I try to play two files simultaneously using aplay, e.g.
$ aplay x.wav $ aplay y.wav
AFAIK first "aplay" will result in play back on default interface/DAI (i.e. 0). What will happen with second aplay? Will it automatically find a free DAI to playback? or it is mandatory to explicitly specify the PCM/card # for second aplay?
Similarly what will happen in case of arecord when a codec supports multiple DAIs capable of capturing?
Hello Ashish
On 1/4/2012 11:06 AM, Ashish Chavan wrote:
I have a codec with multiple TX and RX channels. In ASoC tree, I have seen examples where these kind of codecs are implemented as multichannel codecs. Instead I want it to be treated as card with multiple
Yes, this is totally supported. There are quite a few examples of this in the tree. Your CODEC driver should just implement one DAI per audio interface.
Thanks.
I am looking at some of the examples in the tree and have a small query. I want to know how alsa-utils (aplay, arecord) will behave when a codec driver supports multiple DAIs. For example, let's assume that a codec driver implements two DAIs, both capable of doing stereo playback. Then I try to play two files simultaneously using aplay, e.g.
$ aplay x.wav $ aplay y.wav
AFAIK first "aplay" will result in play back on default interface/DAI (i.e. 0). What will happen with second aplay? Will it automatically find a free DAI to playback?
No,
or it is mandatory to explicitly specify the
PCM/card # for second aplay?
You need to redirect it . You can use
aplay -Dplughw:0,1 x.wav.
Here '0' indicated card number and '1' indicates device number
~Regards Rajeev
Similarly what will happen in case of arecord when a codec supports multiple DAIs capable of capturing?
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
You need to redirect it . You can use
aplay -Dplughw:0,1 x.wav.
Here '0' indicated card number and '1' indicates device number
Is it really mandatory to specify card and device id? Isn't there a middle layer that takes care of using "first free" interface for playback or recording, if interface is not explicitly specified? As we register DAIs with ALSA subsystem, it should be fairly easy for alsa-lib to find out "first free" interface.
I am aware that this wouldn't be practically useful in most cases, because generally we know beforehand which specific interface to be used for playback/recording. In such cases, automatic selection of interface may be confusing to users. But I just want to confirm if this is at all possible?
On 1/4/2012 12:30 PM, Ashish Chavan wrote:
You need to redirect it . You can use
aplay -Dplughw:0,1 x.wav.
Here '0' indicated card number and '1' indicates device number
Is it really mandatory to specify card and device id? Isn't there a middle layer that takes care of using "first free" interface for playback or recording, if interface is not explicitly specified? As we register DAIs with ALSA subsystem, it should be fairly easy for alsa-lib to find out "first free" interface.
I am aware that this wouldn't be practically useful in most cases, because generally we know beforehand which specific interface to be used for playback/recording. In such cases, automatic selection of interface may be confusing to users. But I just want to confirm if this is at all possible?
AFAIK, automatic selection is not there
~Rajeev
On Wed, Jan 04, 2012 at 12:30:01PM +0530, Ashish Chavan wrote:
Is it really mandatory to specify card and device id? Isn't there a middle layer that takes care of using "first free" interface for playback or recording, if interface is not explicitly specified? As we register DAIs with ALSA subsystem, it should be fairly easy for alsa-lib to find out "first free" interface.
That's not implemented since genuinely identical interfaces should be implemented by supporting multiple opens on a single device but those essentailly don't exist in embedded hardware. Pretty much all embedded hardware with multiple routes out of the CPU has either distinct fixed functions for the outputs or independant routing of them so they can't reliably be used interchangibly.
You could implement it but it'd have to be a system specific option to use it.
participants (3)
-
Ashish Chavan -
Mark Brown -
Rajeev kumar