[alsa-devel] aplay lists both Playback and Capture devices
Hi,
When running 'aplay -l' and 'arecord -l' I see the following output on a mx28evk running a 3.10-rc kernel:
/$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: mxssgtl5000 [mxs_sgtl5000], device 0: Playback sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: mxssgtl5000 [mxs_sgtl5000], device 1: Capture sgtl5000-1 [] Subdevices: 1/1 Subdevice #0: subdevice #0
$ arecord -l **** List of CAPTURE Hardware Devices **** card 0: mxssgtl5000 [mxs_sgtl5000], device 0: Playback sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: mxssgtl5000 [mxs_sgtl5000], device 1: Capture sgtl5000-1 [] Subdevices: 1/1 Subdevice #0: subdevice #0
I would expect to see only the Playback entry in aplay and only the Record entry in arecord.
Is there anything I should change in sound/soc/mxs/mxs-sgtl5000.c in order to get the correct outputs?
Regards,
Fabio Estevam
Fabio Estevam wrote:
When running 'aplay -l' and 'arecord -l' I see the following output on a mx28evk running a 3.10-rc kernel:
$ aplay -l card 0: mxssgtl5000 [mxs_sgtl5000], device 0: Playback sgtl5000-0 [] card 0: mxssgtl5000 [mxs_sgtl5000], device 1: Capture sgtl5000-1 [] $ arecord -l card 0: mxssgtl5000 [mxs_sgtl5000], device 0: Playback sgtl5000-0 [] card 0: mxssgtl5000 [mxs_sgtl5000], device 1: Capture sgtl5000-1 []
I would expect to see only the Playback entry in aplay and only the Record entry in arecord.
Please show the contents of /proc/asound/devices.
Regards, Clemens
Hi Clemens,
On Thu, May 30, 2013 at 8:23 AM, Clemens Ladisch clemens@ladisch.de wrote:
I would expect to see only the Playback entry in aplay and only the Record entry in arecord.
Please show the contents of /proc/asound/devices.
Here it goes:
root@freescale /$ cat /proc/asound/devices 0: [ 0] : control 16: [ 0- 0]: digital audio playback 17: [ 0- 1]: digital audio playback 24: [ 0- 0]: digital audio capture 25: [ 0- 1]: digital audio capture 33: : timer
Thanks,
Fabio Estevam
On Sat, Jun 1, 2013 at 3:02 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Clemens,
On Thu, May 30, 2013 at 8:23 AM, Clemens Ladisch clemens@ladisch.de wrote:
I would expect to see only the Playback entry in aplay and only the Record entry in arecord.
Please show the contents of /proc/asound/devices.
Here it goes:
root@freescale /$ cat /proc/asound/devices 0: [ 0] : control 16: [ 0- 0]: digital audio playback 17: [ 0- 1]: digital audio playback 24: [ 0- 0]: digital audio capture 25: [ 0- 1]: digital audio capture 33: : timer
Also, in case it helps:
root@freescale /$ cat /proc/asound/pcm 00-00: HiFi Playback sgtl5000-0 : : playback 1 : capture 1 00-01: HiFi Capture sgtl5000-1 : : playback 1 : capture 1
root@freescale /$ cat /proc/asound/ card0/ devices pcm version cards mxssgtl5000/ timers
root@freescale /$ cat /proc/asound/cards 0 [mxssgtl5000 ]: mxs_sgtl5000 - mxs_sgtl5000 mxs_sgtl5000
root@freescale /$ cat /proc/asound/card0/ id pcm0c/ pcm0p/ pcm1c/ pcm1p/
root@freescale /$ cat /proc/asound/card0/pcm0c/info card: 0 device: 0 subdevice: 0 stream: CAPTURE id: HiFi Playback sgtl5000-0 name: subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1
root@freescale /$ cat /proc/asound/card0/pcm0p/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: HiFi Playback sgtl5000-0 name: subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 root@freescale /$
Regards,
Fabio Estevam
On Sat, Jun 01, 2013 at 03:09:38PM -0300, Fabio Estevam wrote:
root@freescale /$ cat /proc/asound/pcm 00-00: HiFi Playback sgtl5000-0 : : playback 1 : capture 1 00-01: HiFi Capture sgtl5000-1 : : playback 1 : capture 1
Hrm, in that case the kernel does seem to be lying about capabilites... are all the DAIs correctly listing that they're unidirectional?
Hi Mark,
On Sat, Jun 1, 2013 at 4:06 PM, Mark Brown broonie@kernel.org wrote:
On Sat, Jun 01, 2013 at 03:09:38PM -0300, Fabio Estevam wrote:
root@freescale /$ cat /proc/asound/pcm 00-00: HiFi Playback sgtl5000-0 : : playback 1 : capture 1 00-01: HiFi Capture sgtl5000-1 : : playback 1 : capture 1
Hrm, in that case the kernel does seem to be lying about capabilites... are all the DAIs correctly listing that they're unidirectional?
What is the proper way to know this information?
Or how do I tell that each DAI is unidirectional?
Thanks,
Fabio Estevam
On Sat, Jun 1, 2013 at 6:05 PM, Mark Brown broonie@kernel.org wrote:
On Sat, Jun 01, 2013 at 04:20:50PM -0300, Fabio Estevam wrote:
What is the proper way to know this information?
Or how do I tell that each DAI is unidirectional?
If it's not got any playback or capture capabilities.
On mx28evk there are two DAIs connected to a single sgtl5000:
- One corresponds to the serial audio interface 0 (SAIF0) and it is playback only
- The other corresponds to the serial audio interface 1 (SAIF1) and it is capture only.
Should I create and pass device tree bindings like "playback-only" and "capture-only", so that we can avoid having both playback and capture capabilities for SAIF0 and SAIF1?
Or is there already a mechanism in place that I can use to configure a DAI as unidirectional?
Thanks,
Fabio Estevam
On Sat, Jun 01, 2013 at 06:36:49PM -0300, Fabio Estevam wrote:
On Sat, Jun 1, 2013 at 6:05 PM, Mark Brown broonie@kernel.org wrote:
If it's not got any playback or capture capabilities.
On mx28evk there are two DAIs connected to a single sgtl5000:
- One corresponds to the serial audio interface 0 (SAIF0) and it is
playback only
- The other corresponds to the serial audio interface 1 (SAIF1) and it
is capture only.
These are not DAIs, they are DAI links. The capabilities of the links should be being worked out by examining
Should I create and pass device tree bindings like "playback-only" and "capture-only", so that we can avoid having both playback and capture capabilities for SAIF0 and SAIF1?
No, it's not sensible to require users to set DT properties for basic features of the harwdare. If for some reason the interface could be bidirectional but the board design breaks that for some reason then it may make sense but otherwise the kernel ought to be able to work this out based on the fact that one or both ends of the link can only do one direction.
Or is there already a mechanism in place that I can use to configure a DAI as unidirectional?
How is the kernel currently managing to get properties for playback?
Dear Mark Brown,
On Sat, Jun 01, 2013 at 04:20:50PM -0300, Fabio Estevam wrote:
What is the proper way to know this information?
Or how do I tell that each DAI is unidirectional?
If it's not got any playback or capture capabilities.
Each of the SAIFs has only one direction, the question Fabio probably wanted to ask is where he can fix the SAIF caps so they report only one direction instead of both.
Best regards, Marek Vasut
On Sat, Jun 01, 2013 at 11:42:21PM +0200, Marek Vasut wrote:
Each of the SAIFs has only one direction, the question Fabio probably wanted to ask is where he can fix the SAIF caps so they report only one direction instead of both.
Only specifying playback or capture capabilities ought to do the job. Looking at soc-pcm.c it rather looks like things got broken during the soc-pcm stuff if they ever worked for CPU side limitations here.
participants (4)
-
Clemens Ladisch -
Fabio Estevam -
Marek Vasut -
Mark Brown