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