From: Clemens Ladisch <clemens@ladisch.de>
To: John Crowley <jcrowley@screenpc.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: How does usbaudio synchronize on playback?
Date: Fri, 14 Nov 2008 09:33:45 +0100 [thread overview]
Message-ID: <491D37E9.9070901@ladisch.de> (raw)
In-Reply-To: <0MKp8S-1L0ep82OqE-0006QQ@mrelay.perfora.net>
John Crowley wrote:
> [...]
> What I don't understand is how does prepare_playback_urb ensure that more
> playback data has actually been written into the buffer?
It doesn't; the ALSA framework does.
When the driver calls snd_pcm_period_elapsed(), ALSA calls the .pointer
callback and checks if an underrun has happened. Underrun detection
works this way because most sound card hardware reads the data out of
the buffer asynchronously.
> The problem is that we are getting erroneous data, and suspect that it is
> caused by this synchronization issue. When the initial no-data URBs are
> completed, the prepare_playback_urb logic copies a lot of data from the
> buffer into new URBs
The initial URBs should complete one by one, not all at once (this is
the only reason why the driver uses these initial URBs in the first
place).
> but apparently no playback data has been written into the buffer yet
> by the application.
This should result in an underrun and the stream being stopped, except
if your application has disabled this behaviour.
Best regards,
Clemens
--
> This message and any accompanying attachments contains information from
> ScreenPC,Inc. that is confidential and/or privileged. The information is
> intended to be for the use of the individual or entity named above. If you
> are not the intended recipient, be aware that any disclosure, copying,
> distribution or use of the contents of this information is prohibited. If
> you have received this email in error, please notify the sender immediately
> by reply email and destroy all copies of the original email.
*** DISCLAIMER ***
This e-mail contains public information intended for any subscriber of
this mailing list and for anybody else who bothers to read it; it will
be copied, disclosed and distributed to the public. If you think you
are not the intended recipient, please commit suicide immediately.
These terms apply also to any e-mails quoted in, referenced from, or
answering this e-mail, and supersede any disclaimers in those e-mails.
Additionally, disclaimers in those e-mails will incur legal processing
fees of $42 per line; you have agreed to this by reading this
disclaimer.
*** END OF DISCLAIMER ***
next prev parent reply other threads:[~2008-11-14 8:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-13 16:10 How does usbaudio synchronize on playback? John Crowley
2008-11-14 8:33 ` Clemens Ladisch [this message]
2008-11-15 0:38 ` John Crowley
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=491D37E9.9070901@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=jcrowley@screenpc.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.