On Fri, Dec 12, 2008 at 2:59 PM, Takashi Iwai tiwai@suse.de wrote:
At Thu, 11 Dec 2008 22:12:56 +0800, Bryan Wu wrote:
On Thu, Dec 11, 2008 at 9:24 PM, Takashi Iwai tiwai@suse.de wrote:
At Thu, 11 Dec 2008 21:19:21 +0800, Bryan Wu wrote:
On Thu, Dec 11, 2008 at 8:03 PM, Takashi Iwai tiwai@suse.de wrote:
At Thu, 11 Dec 2008 18:40:38 +0800, Bryan Wu wrote:
Hi Takashi,
I just made some progress about this USB audio gadget driver. But I still got some questions about the audio playback. Please kindly help me to work out here, as you're the best one to ask, -:)
I can receive ISO transfer packets from PC host. The packet includes 192 bytes audio data. So I tried to use vfs_write() function to write this 192 bytes to the opened snd card. There is no sound.
Then I create a buffer which is 6K bytes size and a workqueue. I will fill the 6K buffer with the ISO packets data. When the 6K buffer is full, in the workqueue handler I will call vfs_write() function to write these 6K bytes data to the sound card. This time, sound played and it works although it is not very smooth.
So I guess the audio buffer I great is very important to playback audio. How to choose the buffer size? If the size < 6K, there is no sound. I guess it depends on the sound card hardware, but I failed to find any info from hw_params and sw_params.
Well, this pretty much depends on the "sound card" you are accessing. You mentioned about AD1980 but the question is rather what controller is used. The codec chip is basically independent from the DMA transfer parameter.
Right, currently I'm trying AD1980 which using DMA transfer by Blackfin BF54x processor.
Is it an ASoC one?
Yes, it's.
Then another possibility is to create a sort of machine driver communicates with ASoC codec driver instead of accessing to the generic ALSA PCM core.
I hope this driver independents on low level ALSA card implementation. Because on some embedded machine, they don't use ASoC. And I want to push this driver to upstream mainline finally.
Actually, I want to remove the audio buffer here, just write the 192 audio data to sound card directly. Is that possible?
Also depends on the hardware. If the audio chip requires the DMA transfer, you'd need anyway a buffer.
So how to determine the buffer size based on the DMA hardware configuration?
This should be done via usual hw_refine / hw_params ioctls.
in struct snd_pcm_hw_params, I guess only fifo_size is useful for me to choose my buffer size, right?
No, fifo_size is just a place holder, existing only for historical reasons as now.
If the fifo_size == 1K, so how big is OK for my buffer size?
The buffer size is so tricky here, I try to make my driver is independent with the lower card hardware. So I need to find a algorithm to choose the buffer size here.
I tried to change the period_size and buffer_size of the runtime struct. It also didn't work.
Well, the constraint is rather the "slave" sound card. You are actually creating a tunnel driver. The period size and buffer size are issues of the controller, thus you cannot change the parameters of the tunnel driver freely.
Exactly. And another question is whether is it possible using nonblocking writing in my driver?
Why your driver needs to care about non-blocking write? Usually PCM core stuff cares the writing mode and other tasks.
Currently, because this sound playback is not very smooth. I guess there some underrun when I write the USB audio data chuck to the card. So maybe we need 2 buffers as a pingpang buffer to do data buffering. You know, vfs_write() is blocking operation and before it returns we can not fill the buffer if you just have one buffer.
-Bryan