From: Clemens Ladisch <clemens@ladisch.de>
To: melwyn lobo <linux.melwyn@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: XRUN handling
Date: Tue, 06 Jul 2010 14:34:55 +0200 [thread overview]
Message-ID: <4C3322EF.8080505@ladisch.de> (raw)
In-Reply-To: <AANLkTimKA4B8qxbUhlE_3CpCaDOVCS_MpglOiERqS4zS@mail.gmail.com>
melwyn lobo wrote:
>> melwyn lobo wrote:
>>> In case snd_pcm_playback_avail() is less than stop threshold but
>>> greater than 0, then these bytes are missing after Xrun prepare and
>>> start stage.
>>
>> Preparing a stream resets it, i.e., any data currently in the buffer
>> is discarded.
>>
>> If you want to have data in the buffer after preparing, you have to
>> write it again.
>
> Thanks for the confirmation. Our client is working on aplay to test
> our driver in which already there is this issue.
> Is there any workaround in kernel/driver space that could be done
When the ALSA framework tells the driver to stop, and then resets the
pointers, the driver cannot avoid doing this.
Applications have two choices how xruns are to be handled:
1) Stop the stream; the application must then reset the stream (by
preparing it). This mode is selected by using a stop_threshold that
is lower than the buffer_size. This is the default mode.
2) Continue playing. The device will play old data from the ring
buffer, until the application has caught up and written new data
to the buffer. This mode is selected by setting stop_threshold to
the boundary value.
Regards,
Clemens
next prev parent reply other threads:[~2010-07-06 12:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-06 5:03 XRUN handling melwyn lobo
2010-07-06 6:29 ` Clemens Ladisch
2010-07-06 11:05 ` melwyn lobo
2010-07-06 12:34 ` Clemens Ladisch [this message]
2010-07-06 16:16 ` James Courtier-Dutton
2010-07-06 17:46 ` melwyn lobo
2010-07-06 18:39 ` Jaroslav Kysela
2010-07-07 8:11 ` melwyn lobo
2010-07-14 10:17 ` melwyn lobo
2010-07-19 14:37 ` Jaroslav Kysela
2010-07-19 14:43 ` Jaroslav Kysela
2010-07-06 19:37 ` James Courtier-Dutton
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=4C3322EF.8080505@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=linux.melwyn@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.