pcm_lib.c & pcm_memory.c

pcm_lib.c & pcm_memory.c

[Guilhem Tardy]

Hi all,

I would have a few questions regarding buffer mgt:

When is substream->dma_area used for capture or playback? (probably never, as
snd_pcm_lib_malloc_pages() seems to imply that one should only use
substream->runtime->dma_area)

Where should captured audio data be copied into runtime->dma_area? Is it up to
the driver or do capture_copy() and capture_silence() functions take the same
role as for playback?

When does the pointer to the next playback/capture audio period rewind? I
noticed that for more than 2 periods_max, this can happen anytime (eg. after 2,
3, ...) even before we reached the end of the buffer.

Cheers!
Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: pcm_lib.c & pcm_memory.c

[Takashi Iwai]

At Mon, 22 Jul 2002 11:35:40 -0700 (PDT),
Guilhem Tardy wrote:
> 
> Hi all,
> 
> I would have a few questions regarding buffer mgt:
> 
> When is substream->dma_area used for capture or playback? (probably never, as
> snd_pcm_lib_malloc_pages() seems to imply that one should only use
> substream->runtime->dma_area)
 
it's used when the data is copied via copy_from/to_user(), or when the
buffer is mmapped.

please note that you don't need this always.  if you define copy and
silence callbacks, and if they don't handle any dma buffer on the cpu
side (e.g. buffers on a card), then you don't need this.
in such a case, mmap cannot be used.


> Where should captured audio data be copied into runtime->dma_area? Is it up to
> the driver or do capture_copy() and capture_silence() functions take the same
> role as for playback?

yes.  if copy and silence callbacks are defined, then it's up to the
driver.


> When does the pointer to the next playback/capture audio period rewind? I
> noticed that for more than 2 periods_max, this can happen anytime (eg. after 2,
> 3, ...) even before we reached the end of the buffer.

it must be after the hw_ptr reaches the end of the buffer.
please check snd_pcm_update_hw_ptr_interrupt() in pcm_lib.c.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: pcm_lib.c & pcm_memory.c

[Takashi Iwai]

At Wed, 24 Jul 2002 06:53:30 -0700 (PDT),
Guilhem Tardy wrote:
> 
> - Takashi Iwai <tiwai@suse.de> wrote:
> > > Where should captured audio data be copied into runtime->dma_area? Is it up
> > > to the driver or do capture_copy() and capture_silence() functions take the
> > > same role as for playback?
> > 
> > yes.  if copy and silence callbacks are defined, then it's up to the
> > driver.
> 
> OK, then I know how to solve my problem, but it would have been nice to avoid
> copy and silence callbacks, and just get from the substream or runtime
> structure the hw offset where the next period is expected to be written to.

sorry, i don't understand your question.

regardless of the existence of copy callbacks, the hw_ptr is updated
automatically.  it has nothing to do with the behavior of copy/silence.

copy and silence callbacks are called to replace on behalf of
copy_from/to_user().


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: pcm_lib.c & pcm_memory.c

[Guilhem Tardy]

> > OK, then I know how to solve my problem, but it would have been nice to
> > avoid copy and silence callbacks, and just get from the substream or
> > runtime structure the hw offset where the next period is expected to be
> > written to.
> 
> sorry, i don't understand your question.
> 
> regardless of the existence of copy callbacks, the hw_ptr is updated
> automatically.  it has nothing to do with the behavior of copy/silence.
> 
> copy and silence callbacks are called to replace on behalf of
> copy_from/to_user().

Sorry if I wasn't clear. I have seen the snd_pcm_lib_read_transfer(), but
rather than define my own capture copy function, I would have preferred to
write directly to the place in dma_area expected by the framework. In other
words, is the hw offset stored in any structure accessible from a substream?
The other option (that I am pursuing now) is to write a capture_copy() function
and manage my own hw offset in parallel.

Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: pcm_lib.c & pcm_memory.c

[Guilhem Tardy]

> > When does the pointer to the next playback/capture audio period rewind? I
> > noticed that for more than 2 periods_max, this can happen anytime
> > (eg. after 2, 3, ...) even before we reached the end of the buffer.
> 
> it must be after the hw_ptr reaches the end of the buffer.
> please check snd_pcm_update_hw_ptr_interrupt() in pcm_lib.c.

I am having a real hard time understanding
  snd_pcm_update_hw_ptr_interrupt()
  snd_pcm_lib_write_transfer()
  snd_pcm_lib_write1()
 and snd_pcm_lib_write()

For instance, it is not clear to me the relation between runtime->buffer_size
and runtime->boundary ?
What does runtime->hw_ptr_base ?
Should the pointer function wrap at buffer_size, like this:
	pos += data_sent;
	if (pos == buffer_size)
		pos = 0;

Lastly, I have a card that defines the on-board maximum buffer size in samples,
not in bytes. This is the cause of some trouble because the structure
snd_pcm_hardware_t doesn't support such a thing as a buffer_size_max - do you
have any suggestion? As of now, I define buffer_bytes_max for a specific format
(ie. LE16).

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim