[Question] Can I open a substream in kernel space without attach to a file pointer?

[Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

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.

Thanks a lot
-Bryan

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Takashi Iwai]

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.
Any reason why you handle the PCM stuff completely in your driver
code?


Takashi

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

On Wed, Nov 19, 2008 at 9:49 PM, Takashi Iwai <tiwai@suse.de> 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.

Thanks a lot
-Bryan

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Takashi Iwai]

At Wed, 19 Nov 2008 23:42:48 +0800,
Bryan Wu wrote:
> 
> On Wed, Nov 19, 2008 at 9:49 PM, Takashi Iwai <tiwai@suse.de> 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

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

On Thu, Nov 20, 2008 at 12:01 AM, Takashi Iwai <tiwai@suse.de> 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@suse.de> 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.
>

Thanks a lot, Takashi. I almost know the way to do.
I will let you know my progress, because it also communicate with
snd-usb-audio driver.

Best Regards,
-Bryan

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

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.

Actually, I want to remove the audio buffer here, just write the 192
audio data to sound card directly. Is that possible?

Thanks a lot.
-Bryan


On Thu, Nov 20, 2008 at 12:01 AM, Takashi Iwai <tiwai@suse.de> 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@suse.de> 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
>

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Takashi Iwai]

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.

> 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.


Takashi

> 
> Thanks a lot.
> -Bryan
> 
> 
> On Thu, Nov 20, 2008 at 12:01 AM, Takashi Iwai <tiwai@suse.de> 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@suse.de> 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
> >
> 

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

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.

>> 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?
I tried to change the period_size and buffer_size of the runtime struct.
It also didn't work.

Thanks a lot
-Bryan

>
> Takashi
>
>>
>> Thanks a lot.
>> -Bryan
>>
>>
>> On Thu, Nov 20, 2008 at 12:01 AM, Takashi Iwai <tiwai@suse.de> 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@suse.de> 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
>> >
>>
>

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Takashi Iwai]

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?

> >> 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.

> 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.


Takashi

> 
> Thanks a lot
> -Bryan
> 
> >
> > Takashi
> >
> >>
> >> Thanks a lot.
> >> -Bryan
> >>
> >>
> >> On Thu, Nov 20, 2008 at 12:01 AM, Takashi Iwai <tiwai@suse.de> 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@suse.de> 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
> >> >
> >>
> >
> 

Re: [Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

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.

>> >> 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@suse.de> 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@suse.de> 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
>> >> >
>> >>
>> >
>>
>

Re: [alsa-devel] [Question] Can I open a substream in kernel space without attach to a file pointer?

[Takashi Iwai]

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.

> >> >> 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.


Takashi

Re: [alsa-devel] [Question] Can I open a substream in kernel space without attach to a file pointer?

[Bryan Wu]

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

Re: [alsa-devel] [Question] Can I open a substream in kernel space without attach to a file pointer?

[Takashi Iwai]

At Fri, 12 Dec 2008 16:49:30 +0800,
Bryan Wu wrote:
> 
> 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.

If you want to be really generic, the best is to create a driver that
tunnels the data stream to the user-space, and let user-space program
feeds back to the sound card driver.  Doing this in a kernel is an
almost exact pain as user-space.

The efficiency and generic support don't always coexist...

> >> >> >> 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.

You can use snd_pcm_lib_write*() like PCM OSS emulation does instead
of vfs_write().

But, seriously, I recommend you to implement a simple driver first,
that is, behaving as a USB audio class driver and just bypasses the
input stream to the file read.  Then, a user-space program can feed
the stream to any player program, such as aplay.

If this isn't efficient enough, then you can consider go to put the
tunneling stuff into the kernel driver.


Takashi