pointer callback question

pointer callback question

[Tim Blechmann]

[-- Attachment #1.1: Type: text/plain, Size: 839 bytes --]

hi all,

one question about the pointer callback.

the docs say:
>  This callback is called when the PCM middle layer inquires the current
>  hardware position on the buffer. The position must be returned in
frames,
>  ranging from 0 to buffer_size - 1.

i am using a ringbuffer to communicate with my audio device. but when
the position is reset to 0, alsa requests to stop the stream
(SNDRV_PCM_TRIGGER_STOP).

the brief log is (4 periods of 64 frames):
stream_pointer at 64
stream_pointer at 128
stream_pointer at 192
stream_pointer at 256
stream_pointer at 0

after returning 0, a stop is requested.

am i missing something?
thanks, tim

-- 
tim@klingt.org
http://tim.klingt.org

Contrary to general belief, an artist is never ahead of his time but
most people are far behind theirs.
  Edgar Varèse


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: pointer callback question

[Takashi Iwai]

At Thu, 12 Feb 2009 18:50:45 +0100,
Tim Blechmann wrote:
> 
> hi all,
> 
> one question about the pointer callback.
> 
> the docs say:
> >  This callback is called when the PCM middle layer inquires the current
> >  hardware position on the buffer. The position must be returned in
> frames,
> >  ranging from 0 to buffer_size - 1.
> 
> i am using a ringbuffer to communicate with my audio device. but when
> the position is reset to 0, alsa requests to stop the stream
> (SNDRV_PCM_TRIGGER_STOP).
> 
> the brief log is (4 periods of 64 frames):
> stream_pointer at 64
> stream_pointer at 128
> stream_pointer at 192
> stream_pointer at 256

This is invalid.  The pointer callback must return 0 in this case.
The value the pointer callback returns is between 0 and buffer_size-1.


Takashi

> stream_pointer at 0
> 
> after returning 0, a stop is requested.
> 
> am i missing something?
> thanks, tim
> 
> -- 
> tim@klingt.org
> http://tim.klingt.org
> 
> Contrary to general belief, an artist is never ahead of his time but
> most people are far behind theirs.
>   Edgar Varèse
> 

Re: pointer callback question

[Tim Blechmann]

[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]

>> the brief log is (4 periods of 64 frames):
>> stream_pointer at 64
>> stream_pointer at 128
>> stream_pointer at 192
>> stream_pointer at 256
> 
> This is invalid.  The pointer callback must return 0 in this case.
> The value the pointer callback returns is between 0 and buffer_size-1.

sry, typo, 5 periods of 64 frames

-- 
tim@klingt.org
http://tim.klingt.org

The aim of education is the knowledge, not of facts, but of values
  William S. Burroughs


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: pointer callback question

[Takashi Iwai]

At Thu, 12 Feb 2009 18:55:49 +0100,
Tim Blechmann wrote:
> 
> >> the brief log is (4 periods of 64 frames):
> >> stream_pointer at 64
> >> stream_pointer at 128
> >> stream_pointer at 192
> >> stream_pointer at 256
> > 
> > This is invalid.  The pointer callback must return 0 in this case.
> > The value the pointer callback returns is between 0 and buffer_size-1.
> 
> sry, typo, 5 periods of 64 frames

Then it must be OK.  If the stream is stopped, it's likely by the
buffer underrun detection or so...

BTW, you should be sure that the buffer size is aligned to the period 
size if such a design is assumed.  Without the extra constraint, it
could be unaligned as default.


Takashi

Re: pointer callback question

[Tim Blechmann]

[-- Attachment #1.1: Type: text/plain, Size: 974 bytes --]

Takashi Iwai wrote:
> At Thu, 12 Feb 2009 18:55:49 +0100,
> Tim Blechmann wrote:
>>>> the brief log is (4 periods of 64 frames):
>>>> stream_pointer at 64
>>>> stream_pointer at 128
>>>> stream_pointer at 192
>>>> stream_pointer at 256
>>> This is invalid.  The pointer callback must return 0 in this case.
>>> The value the pointer callback returns is between 0 and buffer_size-1.
>> sry, typo, 5 periods of 64 frames
> 
> Then it must be OK.  If the stream is stopped, it's likely by the
> buffer underrun detection or so...

is there any way to compile alsa to get some debugging information about
that?

> BTW, you should be sure that the buffer size is aligned to the period 
> size if such a design is assumed.  Without the extra constraint, it
> could be unaligned as default.

hm, afaict alignment should be ok ...

thnx, tim

-- 
tim@klingt.org
http://tim.klingt.org

A good composer does not imitate; he steals.
  Igor Stravinsky


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: pointer callback question

[Takashi Iwai]

At Thu, 12 Feb 2009 19:04:10 +0100,
Tim Blechmann wrote:
> 
> Takashi Iwai wrote:
> > At Thu, 12 Feb 2009 18:55:49 +0100,
> > Tim Blechmann wrote:
> >>>> the brief log is (4 periods of 64 frames):
> >>>> stream_pointer at 64
> >>>> stream_pointer at 128
> >>>> stream_pointer at 192
> >>>> stream_pointer at 256
> >>> This is invalid.  The pointer callback must return 0 in this case.
> >>> The value the pointer callback returns is between 0 and buffer_size-1.
> >> sry, typo, 5 periods of 64 frames
> > 
> > Then it must be OK.  If the stream is stopped, it's likely by the
> > buffer underrun detection or so...
> 
> is there any way to compile alsa to get some debugging information about
> that?

Did you enable CONFIG_SND_DEBUG=y and others?


Takashi

Re: pointer callback question

[Tim Blechmann]

[-- Attachment #1.1: Type: text/plain, Size: 2852 bytes --]

hello takashi,

>>>> the brief log is (4 periods of 64 frames):
>>>> stream_pointer at 64
>>>> stream_pointer at 128
>>>> stream_pointer at 192
>>>> stream_pointer at 256
>>> This is invalid.  The pointer callback must return 0 in this case.
>>> The value the pointer callback returns is between 0 and buffer_size-1.
>> sry, typo, 5 periods of 64 frames
> 
> Then it must be OK.  If the stream is stopped, it's likely by the
> buffer underrun detection or so...
> 
> BTW, you should be sure that the buffer size is aligned to the period 
> size if such a design is assumed.  Without the extra constraint, it
> could be unaligned as default.

now i am trying to debug it some more. the lx6464es card provides
commands to send audio buffers to the card, and issues an interrupt,
when the buffer has been processed. i am using one dma buffer of
period_bytes*periods (128 frames, 3 bytes per sample, 64 channels, 5
periods)

for the startup, i am sending a number of buffers to the card (periods):
[ 2825.545296] LX6464ES: starting: buffer index 0 on ef620000 (24576 bytes)
[ 2825.545385] LX6464ES: starting: buffer index 1 on ef626000 (24576 bytes)
[ 2825.545474] LX6464ES: starting: buffer index 2 on ef62c000 (24576 bytes)
[ 2825.545568] LX6464ES: starting: buffer index 3 on ef632000 (24576 bytes)
[ 2825.545662] LX6464ES: starting: buffer index 4 on ef638000 (24576 bytes)

for each buffer, the card issues an `end of buffer' interrupt, in which
i send a new buffer to the card and call snd_pcm_period_elapsed with an
updated hw pointer:
[ 2825.548340] LX6464ES: interrupt: gave buffer index 0 on ef620000
(24576 bytes)
[ 2825.548385] LX6464ES: stream_pointer at 128
[ 2825.550986] LX6464ES: interrupt: gave buffer index 1 on ef626000
(24576 bytes)
[ 2825.551029] LX6464ES: stream_pointer at 256
[ 2825.553653] LX6464ES: interrupt: gave buffer index 2 on ef62c000
(24576 bytes)
[ 2825.553695] LX6464ES: stream_pointer at 384
[ 2825.556353] LX6464ES: interrupt: gave buffer index 3 on ef632000
(24576 bytes)
[ 2825.556397] LX6464ES: stream_pointer at 512
[ 2825.559014] LX6464ES: interrupt: gave buffer index 4 on ef638000
(24576 bytes)
[ 2825.559061] LX6464ES: stream_pointer at 0

directly after returning 0 from the pointer callback, alsa requests a stop:
[ 2825.559067] ->lx_pcm_trigger
the timing seems to be fine (2.7 ms for 128 frames).

any idea, why alsa wants to stop the transfer? am i missing something,
like to i need to inform alsa, that the cyclic buffer wraps around?

the code is available at [1]

thanks, tim

[1]
http://tim.klingt.org/git?p=digigram.git;a=shortlog;h=refs/heads/digigram

-- 
tim@klingt.org
http://tim.klingt.org

Relying on the government to protect your privacy is like asking a
peeping tom to install your window blinds.
  John Perry Barlow


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: pointer callback question

[Tim Blechmann]

[-- Attachment #1.1: Type: text/plain, Size: 576 bytes --]

> directly after returning 0 from the pointer callback, alsa requests a stop:
> [ 2825.559067] ->lx_pcm_trigger
> the timing seems to be fine (2.7 ms for 128 frames).
> 
> any idea, why alsa wants to stop the transfer? am i missing something,
> like to i need to inform alsa, that the cyclic buffer wraps around?

hm, answering my own question ... moving card interaction from the
interrupt handler to a tasklet seems to solve the issue now ...

-- 
tim@klingt.org
http://tim.klingt.org

I had nothing to offer anybody except my own confusion
  Jack Kerouac


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel