[alsa-devel] Arecord issue
zonque at gmail.com
Thu Oct 11 16:49:49 CEST 2012
Please do not top-post.
On 11.10.2012 16:44, kartik natarajan wrote:
> At about the same time I check the behaviour on the
> oscilloscope and inferred the same that there is no clock on the bus
> when arecord is executed.
> A little digging further, I see that the codec chip is set to master in
> both cases, aplay and arecord. But somehow it drives the clock in the
> former case and not in the other.
> So this problem is not related to either of aplay/ arecord but more of
> the PCM level behaviour, as it is at this level the master for the bus
> is decided.
Please have a look at the latest changes to this driver found here:
I changed many of these details to make the driver fit into more
environments. If you find a solution to this problem, please post a
patch that applies on top of this tree.
> I'll get back with any information I get on this.
> Your mail has just made my findings easier. Thanks again.
You're welcome :)
> On Thu, Oct 11, 2012 at 6:36 PM, Daniel Mack <zonque at gmail.com
> <mailto:zonque at gmail.com>> wrote:
> On 11.10.2012 14:54, kartik natarajan wrote:
> > I am working on a 2.6.37 kernel and on a DM365 davinci board
> with a
> > tlv320aic3254 audio codec (i2c control lines, i2s data transfer)
> > I wanted to get the audio up on my board so got the alsa-lib and
> > 1.0.25 compiled them and got the aplay to work fine.
> > When I got to working on the arecord things haven't worked fine. I
> > traced all the calls and have reached so far;
> > codec gets set properly
> > davinci_pcm_trigger executes with success
> > snd_pcm_sw_params() executes successfully.
> > aplay calls begin_wave()
> > aplay calls pcm_read() that invokes snd_pcm_readi()
> > Finally my app seems to not go beyond the snd_pcm_start()
> I've been working on a custom AM33xx boards lately which features the
> same digital audio interface than the Davincis do.
> I've been running into similar issues when I tested the recording
> channels, and hooking up a logic analyzer showed that the clocks were
> not driven by the CPU. That causes the DMA engine not receive any
> samples (as the frame and bit clocks are missing), which will eventually
> lead to a timeout.
> This issue was worked around for now by starting the playback first and
> then the record. Unfortunately though, a simply "arecord | aplay" does
> not suffice, as aplay won't start before it received any samples from
> its input side, so you have a deadlock here.
> So I wrote a very simple test tool in order to prove that the overall
> system is working and published it here:
> For the application of this board I'm working on, there's no case where
> we would record anything but not use the output, so this workaround will
> do for me. If you have other requirements, you might need to dig deeper.
> Note that the driver has seem quite some refactorization in 3.7.
> Believe in your dreams, they have a strange way of coming true!!!
More information about the Alsa-devel