From: Ed Wildgoose <lists@wildgooses.com>
To: alsa-devel@lists.sourceforge.net
Subject: patch: RME9632 precise_ptr fix (9652 owners please read)
Date: Wed, 06 Oct 2004 15:10:18 +0100 [thread overview]
Message-ID: <4163FCCA.1090909@wildgooses.com> (raw)
Hooray. With some very kind help from Martin Björnsen, I have figured
out the problem with the rme9652 driver when using the precise_ptr
option and a fix is shown below.
I have not been able to get in touch with Thomas Charbonnel (original
author) for a long time now, so I would be grateful if someone on the
alsa team could commit this to cvs. Please note that I have only tested
this on a 9632 card, but the driver also supports the 9652 (and
others?), so perhaps someone could retest this on those bits of
hardware. It's possible that a similar fix could be applied to the
rme9652.c driver, but I don't really understand which driver is for
which card here?
The justification for this fix being correct is that the position
counter used here is a 16 sample counter (it's not really sample
accurate), and it also counts up continuously, and doesn't reset each
time the buffer is emptied. This created a logic error in the original
code because it was masking against the max buffer size, and not against
the *current* buffer size.
With the fix in below, basic testing on mplayer with some debug code
shows extremely accurate sync rates with the video now, and life is
rosey again!
By the way, if testing against other hardware shows that this patch
causes no problems (and works correctly), which I think it will, then we
can completely remove the accurate_ptr option and make this code the
default. If testers could copy me in directly I will submit a new patch
once a suitable number of responses are received
Thanks
Ed Wildgoose
--- hdsp.c.orig 2004-10-06 14:58:37.052866070 +0100
+++ hdsp.c 2004-10-06 14:59:15.034213752 +0100
@@ -969,8 +969,7 @@
position &= HDSP_BufferPositionMask;
position /= 4;
- position -= 32;
- position &= (HDSP_CHANNEL_BUFFER_SAMPLES-1);
+ position &= ((hdsp->period_bytes/2)-1);
return position;
}
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
next reply other threads:[~2004-10-06 14:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 14:10 Ed Wildgoose [this message]
2004-10-07 12:53 ` patch: RME9632 precise_ptr fix (9652 owners please read) Takashi Iwai
2004-10-08 22:05 ` Ed Wildgoose
2004-10-11 10:29 ` Takashi Iwai
2004-11-11 12:50 ` Ed Wildgoose
2004-11-15 19:07 ` Takashi Iwai
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=4163FCCA.1090909@wildgooses.com \
--to=lists@wildgooses.com \
--cc=alsa-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox