mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bryan Wu" <cooloney@kernel.org>
To: "Takashi Iwai" <tiwai@suse.de>
Cc: "ALSA devel" <alsa-devel@alsa-project.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [alsa-devel] [Question] Can I open a substream in kernel space without attach to a file pointer?
Date: Fri, 12 Dec 2008 16:49:30 +0800	[thread overview]
Message-ID: <386072610812120049n4483b892j2e26ab4a8ece23c@mail.gmail.com> (raw)
In-Reply-To: <s5hej0ddgk5.wl%tiwai@suse.de>

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

  reply	other threads:[~2008-12-12  8:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 10:00 Bryan Wu
2008-11-19 13:49 ` Takashi Iwai
2008-11-19 15:42   ` Bryan Wu
2008-11-19 16:01     ` Takashi Iwai
2008-11-20  6:27       ` Bryan Wu
2008-12-11 10:40       ` Bryan Wu
2008-12-11 12:03         ` Takashi Iwai
2008-12-11 13:19           ` Bryan Wu
2008-12-11 13:24             ` Takashi Iwai
2008-12-11 14:12               ` Bryan Wu
2008-12-12  6:59                 ` [alsa-devel] " Takashi Iwai
2008-12-12  8:49                   ` Bryan Wu [this message]
2008-12-12  9:07                     ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=386072610812120049n4483b892j2e26ab4a8ece23c@mail.gmail.com \
    --to=cooloney@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®