[alsa-devel] Audio Driver Works In Ubuntu but Crash in Debian After 2nd Run
Dear altruists,
I'm writing a sound card driver based on ALSA API. My driver works perfectly on Ubuntu 12.04, 13.10 and 14.04. There is no problem on how many times I play a sound file using my driver. Everything works great. But same driver has some issue on debian distribution.
I've been trying to test it on BeagleBone and during the first run the driver works pretty well. But as soon as I play a second sound file, it crash. I thought may be I did something wrong in releasing resources after 1st run. But so far from my debugging it looks like there is no problem with resource release. Also same driver works on Ubuntu as many times as I test. I even tested with the same sound file. On debian, I get the following message is kernel log-
Apr 23 20:26:41 beaglebone kernel: [ 183.631905] ALSA sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ trouble?)
It would be highly appreciated if I can get some suggestions on which direction I should try to resolve this issue. Is there any known issue with debian distribution or anyone faced similar kind of problem before?
Thanks Azizul Hakim
Any suggestion please?
On Sat, Jun 13, 2015 at 11:18 PM, Azizul Hakim azizulfahim2002@gmail.com wrote:
Dear altruists,
I'm writing a sound card driver based on ALSA API. My driver works perfectly on Ubuntu 12.04, 13.10 and 14.04. There is no problem on how many times I play a sound file using my driver. Everything works great. But same driver has some issue on debian distribution.
I've been trying to test it on BeagleBone and during the first run the driver works pretty well. But as soon as I play a second sound file, it crash. I thought may be I did something wrong in releasing resources after 1st run. But so far from my debugging it looks like there is no problem with resource release. Also same driver works on Ubuntu as many times as I test. I even tested with the same sound file. On debian, I get the following message is kernel log-
Apr 23 20:26:41 beaglebone kernel: [ 183.631905] ALSA sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ trouble?)
It would be highly appreciated if I can get some suggestions on which direction I should try to resolve this issue. Is there any known issue with debian distribution or anyone faced similar kind of problem before?
Thanks Azizul Hakim
Azizul Hakim wrote:
kernel: ALSA sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ trouble?)
This message means that the playback position did not advance.
This typically indicates that your driver did not actually start the DMA, or that interrupts do not arrive correctly, or that your .pointer callback is buggy.
Regards, Clemens
So I've three possible scenario:
Driver didn't start the DMA: Not sure how to track on this point. Any suggestion?
Interrupt do not arrive correctly: Is this the hardware issue or ALSA issue?
.pointer callback is buggy: It makes some sense to me but I'm confused about it though. Will check on this point.
Thanks Azizul Hakim wrote:
kernel: ALSA sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ
trouble?)
This message means that the playback position did not advance.
This typically indicates that your driver did not actually start the DMA, or that interrupts do not arrive correctly, or that your .pointer callback is buggy.
Regards, Clemens
Azizul Hakim wrote:
Driver didn't start the DMA: Not sure how to track on this point. Any suggestion? Interrupt do not arrive correctly: Is this the hardware issue or ALSA issue?
These would imply that some your driver, or some code used by your driver, did not configure the DMA/interrupt correctly.
Regards, Clemens
+ Peter for Beaglebone
On Wed, 2015-06-17 at 10:01 +0200, Clemens Ladisch wrote:
Azizul Hakim wrote:
Driver didn't start the DMA: Not sure how to track on this point. Any suggestion? Interrupt do not arrive correctly: Is this the hardware issue or ALSA issue?
These would imply that some your driver, or some code used by your driver, did not configure the DMA/interrupt correctly.
On beaglebone it may also be that the McBSP port clocking is not configured correctly.
Liam
Okay, its good to learn something new on every day. So how do I configure McBSP port clocking? I'm very new on these things and was unable to find any useful link on this point. :(
On Wed, Jun 17, 2015 at 5:05 AM, Liam Girdwood < liam.r.girdwood@linux.intel.com> wrote:
- Peter for Beaglebone
On Wed, 2015-06-17 at 10:01 +0200, Clemens Ladisch wrote:
Azizul Hakim wrote:
Driver didn't start the DMA: Not sure how to track on this point. Any
suggestion?
Interrupt do not arrive correctly: Is this the hardware issue or ALSA
issue?
These would imply that some your driver, or some code used by your
driver,
did not configure the DMA/interrupt correctly.
On beaglebone it may also be that the McBSP port clocking is not configured correctly.
Liam
I discovered one thing which lead me to believe something is wrong in my *.pointer* callback. I would like to share it for expert suggestions.
So when a audio playback starts I initialize the buffer pointer to "0" in the *.prepare* function. During my 1st playback the audio driver works great, I see the *.pointer* function getting called a lot of times.
I update the buffer pointer in the URB completion function. Here goes a code segment from my URB completion function:
https://gist.github.com/azizulhakim/d24a36ef753f9a1536fa
And this is my *.pointer* function:
https://gist.github.com/azizulhakim/b15b002f74e77f88cd5a
Now during the 2nd playback, the driver initializes the buffer pointer to "0" again inside the *.prepare* function. And then I see it calls the *.pointer* function only once and afterwards stop with the error message *ALSA sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ trouble?)*
So I stopped initializing the buffer pointer to "0" during the second playback assuming that the buffer pointer should stay at the place it stopped from previous playback. But that also didn't work for me. I get the same error message. Note that same driver works on Ubuntu without any problem and as many times as I want.
It would be really helpful if I get some suggestion from the given code. In case you wonder, the full code is available here https://github.com/azizulhakim/beagleusb/blob/master/beagle-audio.c
Thanks Azizul
On Wed, Jun 17, 2015 at 10:53 AM, Azizul Hakim azizulfahim2002@gmail.com wrote:
Okay, its good to learn something new on every day. So how do I configure McBSP port clocking? I'm very new on these things and was unable to find any useful link on this point. :(
On Wed, Jun 17, 2015 at 5:05 AM, Liam Girdwood < liam.r.girdwood@linux.intel.com> wrote:
- Peter for Beaglebone
On Wed, 2015-06-17 at 10:01 +0200, Clemens Ladisch wrote:
Azizul Hakim wrote:
Driver didn't start the DMA: Not sure how to track on this point. Any
suggestion?
Interrupt do not arrive correctly: Is this the hardware issue or ALSA
issue?
These would imply that some your driver, or some code used by your
driver,
did not configure the DMA/interrupt correctly.
On beaglebone it may also be that the McBSP port clocking is not configured correctly.
Liam
Hi,
On Jun 19 2015 13:32, Azizul Hakim wrote:
Now during the 2nd playback, the driver initializes the buffer pointer to "0" again inside the *.prepare* function. And then I see it calls the *.pointer* function only once and afterwards stop with the error message *ALSA sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ trouble?)*
When you see this log with playback PCM application, it means that 'the application is running in blocking-mode (O_NONBLOCK) with no-period-wakeup mode, and the blocking continues during 10 seconds'. (when period-size is too large, it continues longer than 10 seconds.)
The blocking mode is released by several cues, but in this case I think we should focus on calling 'snd_pcm_period_elapsed()'. In ALSA PCM driver, calling this function changes PCM ringbuffer status, then releases the blocking state in some conditions.
Therefore, we can judge that your driver may call no 'snd_pcm_period_elapsed()' because receiving no 'struct urb.complete()' callback.
I think you should check your 'beagleaudio_audio_start()' function and confirm whether it can set/release USB subsystem correctly.
Additionally, I reccomend you to use URB monitor in runtime to see your driver can transmit URBs in second playbacking. (In my memory, Wireshark has the functionality.)
So I stopped initializing the buffer pointer to "0" during the second playback assuming that the buffer pointer should stay at the place it stopped from previous playback. But that also didn't work for me. I get the same error message. Note that same driver works on Ubuntu without any problem and as many times as I want.
The zero-reset is needed, I think.
In your driver, 'struct beagleaudio.snd_buffer_pos' and 'struct beagleaudio.snd_period_pos' are used to count the number of PCM frames in a period or a buffer.
They're an alternative representation of ALSA PCM rung-buffer status, and no need to keep the state in different PCM runtimes. It's good to reset them before PCM substream is running. (typically, done in 'struct snd_pcm_ops.prepare()' callback).
# I note that I'm not good at USB subsystem and USB Audio Device Class. # My comments come from general knowledgement about ALSA PCM core.
Regards
Takashi Sakamoto
On Jun 19 2015 14:56, Takashi Sakamoto wrote:
The blocking mode is released by several cues, but in this case I think we should focus on calling 'snd_pcm_period_elapsed()'. In ALSA PCM driver, calling this function changes PCM ringbuffer status, then releases the blocking state in some conditions.
Oops. 'The blocking state is released by several cues,' is correct.
Takashi Sakamoto
On Jun 19 2015 14:56, Takashi Sakamoto wrote:>
When you see this log with playback PCM application, it means that 'the application is running in blocking-mode (O_NONBLOCK) with no-period-wakeup mode
Oops, again.
'without non-period-wakeup mode' is correct...
# I'm a bit tired from the humidity in this rainy season...
Regards
Takashi Sakamoto
Azizul Hakim wrote:
So when a audio playback starts I initialize the buffer pointer to "0" in the *.prepare* function.
This is correct.
https://gist.github.com/azizulhakim/d24a36ef753f9a1536fa https://gist.github.com/azizulhakim/b15b002f74e77f88cd5a
This is not; the code confuses bytes and frames.
When in doubt, give _all_ variables a "_bytes" or "_frames" suffix, and check that _every_ access uses the correct units.
Regards, Clemens
I discovered one thing which lead me to believe something is wrong in my *.pointer* callback. I would like to share it for expert suggestions.
So when a audio playback starts I initialize the buffer pointer to "0" in the *.prepare* function. During my 1st playback the audio driver works great, I see the *.pointer* function getting called a lot of times.
I update the buffer pointer in the URB completion function. Here goes a code segment from my URB completion function:
https://gist.github.com/azizulhakim/d24a36ef753f9a1536fa
And this is my *.pointer* function:
https://gist.github.com/azizulhakim/b15b002f74e77f88cd5a
Now during the 2nd playback, the driver initializes the buffer pointer to "0" again inside the *.prepare* function. And then I see it calls the *.pointer* function only once and afterwards stop with the error message
*ALSA
sound/core/pcm_lib.c:1910 playback write error (DMA or IRQ trouble?)*
So I stopped initializing the buffer pointer to "0" during the second playback assuming that the buffer pointer should stay at the place it stopped from previous playback. But that also didn't work for me. I get
the
same error message. Note that same driver works on Ubuntu without any problem and as many times as I want.
It would be really helpful if I get some suggestion from the given code.
In
case you wonder, the full code is available here <https://github.com/azizulhakim/beagleusb/blob/master/beagle-audio.c
Do your driver really support one period per buffer when you specify .periods_min = 1 ?
On 06/17/2015 05:53 PM, Azizul Hakim wrote:
Okay, its good to learn something new on every day. So how do I configure McBSP port clocking? I'm very new on these things and was unable to find any useful link on this point. :(
I don't see anything in the driver [1] which would indicate that the issue is in any ways specific to BeagleBone (apart from the beagleaudio strings in the driver). You are not using the McASP, nor the edma-pcm/davinci-pcm. What you seams to have is a custom sound card driver for USB. Is there a reason why you could not use the already available USB sound card for this?
Are you running exactly the same kernel under ubuntu and debian?
Yes, I tested with kernel 3.8.13 in both ubuntu and beaglebone.
On Mon, Jun 22, 2015 at 2:55 AM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 06/17/2015 05:53 PM, Azizul Hakim wrote:
Okay, its good to learn something new on every day. So how do I configure McBSP port clocking? I'm very new on these things and was unable to find
any
useful link on this point. :(
I don't see anything in the driver [1] which would indicate that the issue is in any ways specific to BeagleBone (apart from the beagleaudio strings in the driver). You are not using the McASP, nor the edma-pcm/davinci-pcm. What you seams to have is a custom sound card driver for USB. Is there a reason why you could not use the already available USB sound card for this?
Are you running exactly the same kernel under ubuntu and debian?
-- Péter
[1] https://github.com/azizulhakim/beagleusb/blob/master/beagle-audio.c
On Wed, Jun 17, 2015 at 5:05 AM, Liam Girdwood <liam.r.girdwood@linux.intel.com mailto:liam.r.girdwood@linux.intel.com>
wrote:
+ Peter for Beaglebone On Wed, 2015-06-17 at 10:01 +0200, Clemens Ladisch wrote: > Azizul Hakim wrote: > > Driver didn't start the DMA: Not sure how to track on thispoint. Any
suggestion? > > Interrupt do not arrive correctly: Is this the hardware issue orALSA
issue? > > These would imply that some your driver, or some code used by yourdriver,
> did not configure the DMA/interrupt correctly. On beaglebone it may also be that the McBSP port clocking is not configured correctly. Liam
On Mon, 22 Jun 2015 11:00:42 -0400 Azizul Hakim azizulfahim2002@gmail.com wrote:
Yes, I tested with kernel 3.8.13 in both ubuntu and beaglebone.
On Mon, Jun 22, 2015 at 2:55 AM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
[...]
Are you running exactly the same kernel under ubuntu and debian?
[...]
Excuse me, Azizul, but in the thread you compare ubuntu and debian and then here you say "ubuntu and beaglebone", do you mean:
- Ubuntu on _PC_ and Debian on _beglebone_?
Maybe it's a silly question, but better be sure, because the distribution should not make a huge difference when using the same kernel, but the architecture does if it's a memory issue.
And please try to avoid top-posting :)
Ciao, Antonio
participants (7)
-
Antonio Ospite -
Azizul Hakim -
Clemens Ladisch -
Liam Girdwood -
Peter Ujfalusi -
Raymond Yau -
Takashi Sakamoto