[alsa-devel] pointer callback question
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
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
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
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
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
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
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
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 ...
participants (2)
-
Takashi Iwai -
Tim Blechmann