On Thu, Dec 11, 2008 at 9:24 PM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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. >> >> 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? 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? Thanks a lot for your patient answer. -Bryan > > Takashi > >> >> Thanks a lot >> -Bryan >> >> > >> > Takashi >> > >> >> >> >> Thanks a lot. >> >> -Bryan >> >> >> >> >> >> On Thu, Nov 20, 2008 at 12:01 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> >> > At Wed, 19 Nov 2008 23:42:48 +0800, >> >> > Bryan Wu wrote: >> >> >> >> >> >> On Wed, Nov 19, 2008 at 9:49 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> >> >> > At Wed, 19 Nov 2008 18:00:36 +0800, >> >> >> > Bryan Wu wrote: >> >> >> >> >> >> >> >> Hi Takashi, >> >> >> >> >> >> >> >> I am developing a USB gadget driver compliant to USB Audio Class Spec 2.0. >> >> >> >> So I want to open a PCM substream and do some playback of capture, >> >> >> >> then close them? >> >> >> >> >> >> >> >> I found snd_pcm_open_substream() is for opening a substream and attach >> >> >> >> it to a file. >> >> >> >> But in my application, there is no need to open a file before opening >> >> >> >> a substream. >> >> >> >> >> >> >> >> - Is there any interface for me to open a substream in kernel space >> >> >> >> without attach to a file? >> >> >> >> - How to playback and capture in kernel space, use snd_pcm_lib_write >> >> >> >> and snd_pcm_lib_read? >> >> >> >> - How to get the snd_pcm_hardware struct from low level driver, >> >> >> >> because I have to get the hardware configuration of the snd pcm >> >> >> >> device? >> >> >> >> >> >> >> >> And I am reading the code of OSS emulator in ALSA. It provides some >> >> >> >> info about the kernel space sound card programming. >> >> >> > >> >> >> > Yes, OSS emulation code handles the PCM in the kernel. >> >> >> > But, basically I don't recommend you to do this -- it's not the job of >> >> >> > the sound card driver. The whole PCM stuff is handled by the PCM >> >> >> > middle layer, not the driver itself. >> >> >> >> >> >> No, my plan is not a sound card driver. It is an USB gadget audio driver. >> >> >> When an embedded system for example Blackfin board connects to a USB host (PC), >> >> >> PC will recognize this USB device as a USB Audio Class device. >> >> >> >> >> >> Generally, there should be a sound card on the embedded system. Our >> >> >> Blackfin board >> >> >> has an AD1980 ALSA sound card. The USB gadget audio driver will open this sound >> >> >> card and export this device to USB host PC by some USB audio class specific >> >> >> descriptors. Then the PC can playback some audio stream by USB cable, USB gadget >> >> >> audio driver will receive this stream and playback the data by AD1980 >> >> >> ALSA playback >> >> >> substream. Capture is the similar. >> >> >> >> >> >> > Any reason why you handle the PCM stuff completely in your driver >> >> >> > code? >> >> >> > >> >> >> >> >> >> There is USB gadget MIDI driver in kernel. But it asked the user to >> >> >> use aconnect tool to >> >> >> connect the virtual MIDI card to a real one. I don't want travel to >> >> >> user space and it should >> >> >> be more efficient in kernel space to handle all things including PCM >> >> >> open/release/read/write >> >> >> and Mixer control. >> >> >> >> >> >> Any hints about this? I really need some help from ALSA guru, cause >> >> >> I'm not familiar the internal >> >> >> things here. >> >> > >> >> > Well, the access in the kernel space is fairly similar as in the user >> >> > space. It opens, issues ioctls, reads and writes. The difference is >> >> > that you access via dedicated function calls instead of syscalls. >> >> > There is no way to poke the driver internal from other drivers. >> >> > To answer your questions... >> >> > >> >> >> >> - Is there any interface for me to open a substream in kernel space >> >> >> >> without attach to a file? >> >> > >> >> > No. >> >> > >> >> >> >> - How to playback and capture in kernel space, use snd_pcm_lib_write >> >> >> >> and snd_pcm_lib_read? >> >> > >> >> > Yes. But for the kernel space buffer, you'd need to fake the >> >> > user-space pointer by snd_enter_user() and snd_leave_user(). See >> >> > snd_pcm_oss_write3(). >> >> > >> >> >> >> - How to get the snd_pcm_hardware struct from low level driver, >> >> >> >> because I have to get the hardware configuration of the snd pcm >> >> >> >> device? >> >> > >> >> > Not way to peek/poke the driver internals from the outside. >> >> > You'll need to negotiate via snd_pcm_kernel_ioctl() like user-space >> >> > programs. >> >> > >> >> > >> >> > HTH, >> >> > >> >> > Takashi >> >> > >> >> >> > >> > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
