playback audio overwritten before it is sent to the card

playback audio overwritten before it is sent to the card

[Guilhem Tardy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2730 bytes --]

Hi,

I think that I got around understanding snd_pcm_update_hw_ptr_interrupt() now.
The reason of my enquiries is that I get a very strange behaviour while playing
back audio on a sound card: the playback_copy() function is called too many
times before audio is actually played out, thus overwriting the buffer. For
instance, with 2 periods of 160 bytes (buffer_size = 320):

playback_prepare() on sound dev0
snd_pci2103_mode() on sound dev0,  bsize:320  psize:160  pnsam:160
playback_prepare() on sound dev0
playback_copy() on sound dev0,  pos:0 ->160
    from d0865000 to c19e0000: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ
card 0: Sending Audio_Data  fmt:1  cnt:160 (160 bytes)  last:0  pos:160
tasklet: send 24 bytes of dataPayload (including 0 bytes of mmTags)
tasklet: send 160 bytes of extPayload from c19e0000 to 800020a0
    ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ
playback_pointer() on sound dev0,  last:160  pos:160  ptr:160
playback_prepare() on sound dev0
playback_copy() on sound dev0,  pos:160 ->320
    from d0865000 to c19e00a0: g ÿ ÿ ÿ ÿ ÿ ÿ ÿ
playback_pointer() on sound dev0,  last:160  pos:320  ptr:160
playback_copy() on sound dev0,  pos:0 ->160
    from d0865000 to c19e0000: g g [ [ [ S S S
playback_prepare() on sound dev0
playback_copy() on sound dev0,  pos:160 ->320
    from d0865000 to c19e00a0: g g [ [ [ S S S
playback_pointer() on sound dev0,  last:160  pos:320  ptr:160
playback_copy() on sound dev0,  pos:0 ->160
    from d0865000 to c19e0000: Û ç ç ç ÿ ÿ ÿ g
playback_prepare() on sound dev0
playback_copy() on sound dev0,  pos:160 ->320
    from d0865000 to c19e00a0: Û ç ç ç ÿ ÿ ÿ g
playback_pointer() on sound dev0,  last:160  pos:320  ptr:160
playback_copy() on sound dev0,  pos:0 ->160
    from d0865000 to c19e0000: Ó Û Û Û Û Û Û Û
playback_prepare() on sound dev0
playback_copy() on sound dev0,  pos:160 ->320
    from d0865000 to c19e00a0: Ó Û Û Û Û Û Û Û
card 0: Sending Audio_Data  fmt:1  cnt:160 (160 bytes)  last:160  pos:320
tasklet: send 24 bytes of dataPayload (including 0 bytes of mmTags)
tasklet: send 160 bytes of extPayload from c19e00a0 to 80002220
    Ó Û Û Û Û Û Û Û
playback_pointer() on sound dev0,  last:320  pos:320  ptr:0


This is puzzling, and the fact that I moved from ALSA rc1 to rc2 at the same
time that I was changing some aspects of the driver make it more difficult to
trace where the error comes from. Can any of you make something out of that
log?

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: playback audio overwritten before it is sent to the card

[Guilhem Tardy]

I am getting to know all the internals (although I didn't really want to)...
the ops->pointer() is called only from snd_pcm_update_hw_ptr(), which updates
the runtime->status->hw_ptr. But it doesn't:

  playback_copy() on sound dev0,  hwoff:0  pos:0 ->160

  playback_pointer() on sound dev0,  last:160  pos:160
     ptr:160  {hw:0, appl:160}
     hw_ptr_base:0  min_align:1  avail_min:160  avail_max:0

So far, so good. In snd_pcm_update_hw_ptr(), new_hw_ptr = runtime->hw_ptr_base
+ pos = 160, so the next time around it should read "hw:160"...

  playback_prepare() on sound dev0,  bsize:320  boundary:1342177280

Is it normal that boundary is so high?

  playback_copy() on sound dev0,  hwoff:0  pos:160 ->320

  playback_pointer() on sound dev0,  last:160  pos:320  ptr:160
     {hw:0, appl:160}
     hw_ptr_base:0  min_align:1  avail_min:160  avail_max:320

Ouch! "hw:0"... Why didn't change? And runtime->control->appl_ptr hasn't
changed either?

  playback_copy() on sound dev0,  hwoff:160  pos:0 ->160

Keep copying to the buffer in runtime->dma_area...

  playback_prepare() on sound dev0,  bsize:320  boundary:1342177280
  playback_copy() on sound dev0,  hwoff:0  pos:160 ->320

Ouch! This one hasn't been sent to the card yet.

Looks like I am having serious trouble here. Any hint very welcome.

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: playback audio overwritten before it is sent to the card

[Takashi Iwai]

At Fri, 26 Jul 2002 13:51:01 -0700 (PDT),
Guilhem Tardy wrote:
> 
> 
> I am getting to know all the internals (although I didn't really want to)...
> the ops->pointer() is called only from snd_pcm_update_hw_ptr(), which updates
> the runtime->status->hw_ptr. But it doesn't:
> 
>   playback_copy() on sound dev0,  hwoff:0  pos:0 ->160
> 
>   playback_pointer() on sound dev0,  last:160  pos:160
>      ptr:160  {hw:0, appl:160}
>      hw_ptr_base:0  min_align:1  avail_min:160  avail_max:0
> 
> So far, so good. In snd_pcm_update_hw_ptr(), new_hw_ptr = runtime->hw_ptr_base
> + pos = 160, so the next time around it should read "hw:160"...
> 
>   playback_prepare() on sound dev0,  bsize:320  boundary:1342177280
> 
> Is it normal that boundary is so high?

the boundary is not the buffer size (although it's aligned to the
buffer size).
it's the maximal size of the buffer pointer which is countable by an
(long) integer.  the buffer pointer will be rewound to zero after it
reaches this value.


> 
>   playback_copy() on sound dev0,  hwoff:0  pos:160 ->320
> 
>   playback_pointer() on sound dev0,  last:160  pos:320  ptr:160
>      {hw:0, appl:160}
>      hw_ptr_base:0  min_align:1  avail_min:160  avail_max:320
> 
> Ouch! "hw:0"... Why didn't change? And runtime->control->appl_ptr hasn't
> changed either?

because the prepare() was called before this operation.

> 
>   playback_copy() on sound dev0,  hwoff:160  pos:0 ->160
> 
> Keep copying to the buffer in runtime->dma_area...
> 
>   playback_prepare() on sound dev0,  bsize:320  boundary:1342177280
>   playback_copy() on sound dev0,  hwoff:0  pos:160 ->320
> 
> Ouch! This one hasn't been sent to the card yet.
 
again prepare() was called.  hence, the hwoff was rewound.

but i don't know what happens here:  why prepare() is called.
does your application calls snd_pcm_prepare() so often?

basically, prepare callback is called only from snd_pcm_prepare() in
pcm_native.c, i.e. only via ioctl.  (or, in the case of OSS emulation,
via snd_pcm_oss_prepare(), which can be called multiple times at each
change of configuration).


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: playback audio overwritten before it is sent to the card

[Takashi Iwai]

At Tue, 30 Jul 2002 08:19:16 -0700 (PDT),
Guilhem Tardy wrote:
> 
> > basically, prepare callback is called only from snd_pcm_prepare() in
> > pcm_native.c, i.e. only via ioctl.  (or, in the case of OSS emulation,
> > via snd_pcm_oss_prepare(), which can be called multiple times at each
> > change of configuration).
> 
> The configuration doesn't change. I play a test file, that's it.

as mentioned shortly, oss emulation may call prepare multiple times.
since the oss driver changes the configuration by calling ioctls many
times, e.g. one for sample rate, one for sample format, etc., at each
time these ioctls are called, prepare callback is called, too, to
reflect the change of configuration.

 
Takashi


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: success (WAS: playback audio overwritten before it is sent to the card)

[Guilhem Tardy]

Takashi,

I have now the playout AND recording alright, thanks to your explanation. Now,
I reset my pointers in prepare(), which makes pointer() return a value
meaningful to the rest of the ALSA framework.

A big THANK YOU!
Guilhem.

PS: Regarding ADPCM, I hope that we'll manage to get other bit rates in there -
I will look into this at my return from holidays (2nd-12th of August). Then
remains the problem of how one should distinguish different bit rates (I think
of checking on the driver side the runtime->sample_bits).


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


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

PCM ioctls

[Guilhem Tardy]

Hi,

There are 3 standard PCM ioctls, and a driver could potentially support others
via its own ioctl function registered in the snd_pcm_ops_t structure. Could
anyone give me a hint regarding how an application could then call such
standard and other ioctls?

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: PCM ioctls

[Paul Davis]

>There are 3 standard PCM ioctls, and a driver could potentially support others
>via its own ioctl function registered in the snd_pcm_ops_t structure. Could
>anyone give me a hint regarding how an application could then call such
>standard and other ioctls?

i'm not going to do that, but i will point you at the "hwdep" API,
which exists specifically to provide a way to make hw-dependent
operations available that don't map into the existing ALSA API. you
create a hwdep device within the driver; apps can open it, and call
whatever ioctl's you provide. 

its a bad idea for general purpose software, of course, since such s/w
can't know about your specific ioctls, but it works well for writing
h/w specific control apps. i have an app for the wavefront synth, for
example, which has a whole bunch of operations that don't fit into any
of the existing PCM, MIDI or Sequencer APIs. these are implemented via
the hwdep API, such as it is.

--p


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

ADPCM 16kbps and other formats

[Guilhem Tardy]

Hi,

It is my understanding that the SNDRV_PCM_FORMAT_IMA_ADPCM format supported by
ALSA is the 32kbps variant of G.726 standard in telephony (vs. propriatory
variants like MS-ADPCM).

I would like to add support for at least the 16kbps variant of G.726 (24kbps
and 40kbps are other possibilities), and wonder if an entirely different format
should be used for each (vs. one G.726 format and PCM subtypes)?

Of course, any hints as to how one adds new PCM formats to ALSA would be
immensely welcomed.

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390