[alsa-devel] arecord: main:552: audio open error: Invalid argument
Liam and Mark,
I created a log with some printks that kinda show what's going on. In one process I run speaker-test, and then I start arecord in another process.
fsl_ssi_startup:286 substream=ef3e5000 playback=0 capture=0 fsl_ssi_startup:288 rtd=ef3a2c00 rate=0 fsl_ssi_startup:298 fsl_ssi_startup:373 first=(null) second=(null) fsl_ssi_startup:427 soc_pcm_open:381 fsl_dma_open:408 rtd=ef3a2c00 rate=0 soc_pcm_open:391 soc_pcm_open:402 soc_pcm_open:412 soc_pcm_open:463 soc_pcm_open:471 soc_pcm_open:477 soc_pcm_open:484 asoc: cs4270-hifi <-> e0016000.ssi info: asoc: rate mask 0x40001fff asoc: min ch 2 max ch 2 asoc: min rate 5512 max rate 192000 fsl_ssi_hw_params:450 Rate set to 48000Hz (requested 48000Hz) fsl_dma_hw_params:579 soc_pcm_hw_params:748 rtd=ef3a2c00 rate=48000
... fsl_ssi_startup:286 substream=ef3e5300 playback=1 capture=0 fsl_ssi_startup:288 rtd=ef3a2d10 rate=0 fsl_ssi_startup:373 first=ef3e5000 second=(null) fsl_ssi_startup:411 runtime=ef4ba800 sample_bits=16 fsl_ssi_startup:427 soc_pcm_open:381 fsl_dma_open:408 rtd=ef3a2d10 rate=0 <<------ soc_pcm_open:391 soc_pcm_open:402 soc_pcm_open:412 soc_pcm_open:463 soc_pcm_open:471 soc_pcm_open:477 soc_pcm_open:484 soc_pcm_apply_symmetry:335 rtd=ef3a2d10 rate=0 capture: Symmetry forces 0Hz rate
In summary, the problem appears to be that asoc calls soc_pcm_apply_symmetry() in soc_pcm_open(), but this occurs before soc_pcm_hw_params() can set rtd->rate. So rtd->rate is always zero when soc_pcm_apply_symmetry() is called.
For some reason, this isn't a problem when arecord is started before speaker-test. In that case, rtd->rate is 48000 when speaker-test is started:
fsl_ssi_startup:286 substream=ef3e5300 playback=0 capture=0 fsl_ssi_startup:288 rtd=ef3e6d10 rate=0 fsl_ssi_startup:298 fsl_ssi_startup:373 first=(null) second=(null) fsl_ssi_startup:427 soc_pcm_open:382 fsl_dma_open:408 rtd=ef3e6d10 rate=0 soc_pcm_open:392 soc_pcm_open:403 soc_pcm_open:413 soc_pcm_open:464 soc_pcm_open:472 soc_pcm_open:478 soc_pcm_open:485 asoc: cs4270-hifi <-> e0016000.ssi info: asoc: rate mask 0x40001fff asoc: min ch 2 max ch 2 asoc: min rate 5512 max rate 192000 fsl_ssi_hw_params:450 fsl_dma_hw_params:579 soc_pcm_hw_params:749 rtd=ef3e6d10 rate=48000 pop wq checking: Playback status: inactive waiting: yes ... fsl_ssi_startup:286 substream=ef3e5000 playback=0 capture=1 fsl_ssi_startup:288 rtd=ef3e6c00 rate=48000 fsl_ssi_startup:373 first=ef3e5300 second=(null) fsl_ssi_startup:411 runtime=ef4c6c00 sample_bits=16 fsl_ssi_startup:427 soc_pcm_open:382 fsl_dma_open:408 rtd=ef3e6c00 rate=48000 <<------ soc_pcm_open:392 soc_pcm_open:403 soc_pcm_open:413 soc_pcm_open:464 soc_pcm_open:472 soc_pcm_open:478 soc_pcm_open:485 soc_pcm_apply_symmetry:333 rtd=ef3e6c00 rate=48000 playback: Symmetry forces 48000Hz rate asoc: cs4270-hifi <-> e0016000.ssi info: asoc: rate mask 0x40001fff asoc: min ch 2 max ch 2 asoc: min rate 5512 max rate 192000 fsl_ssi_hw_params:450 Rate set to 48000Hz (requested 48000Hz) fsl_dma_hw_params:579 Buffer soc_pcm_hw_params:749 rtd=ef3e6c00 rate=48000
On Wed, Aug 04, 2010 at 02:55:45PM -0500, Timur Tabi wrote:
I created a log with some printks that kinda show what's going on. In one process I run speaker-test, and then I start arecord in another process.
You might want to provide a little more context on what you're trying to do here for the benefit of readers...
In summary, the problem appears to be that asoc calls soc_pcm_apply_symmetry() in soc_pcm_open(), but this occurs before soc_pcm_hw_params() can set rtd->rate. So rtd->rate is always zero when soc_pcm_apply_symmetry() is called.
For some reason, this isn't a problem when arecord is started before speaker-test. In that case, rtd->rate is 48000 when speaker-test is started:
The symmetric_rates infrastructure was only ever really intended to work over a single DAI so I'd not be at all surprised if it gets a little confused (though I'm surprised it's doing anything at all).
On Wed, Aug 4, 2010 at 3:01 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
The symmetric_rates infrastructure was only ever really intended to work over a single DAI so I'd not be at all surprised if it gets a little confused (though I'm surprised it's doing anything at all).
Makes sense. Should I forget the symmetric_rates feature and just handle it internally in my driver?
On Wed, Aug 04, 2010 at 04:15:36PM -0500, Timur Tabi wrote:
On Wed, Aug 4, 2010 at 3:01 PM, Mark Brown
The symmetric_rates infrastructure was only ever really intended to work over a single DAI so I'd not be at all surprised if it gets a little confused (though I'm surprised it's doing anything at all).
Makes sense. Should I forget the symmetric_rates feature and just handle it internally in my driver?
It would seem more sensible to enhance symmetric_rates.
participants (2)
-
Mark Brown -
Timur Tabi