From: James Courtier-Dutton <James@superbug.demon.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: OPL3-SA2/3 PCM Playback rates?
Date: Wed, 09 Oct 2002 19:09:16 +1000 [thread overview]
Message-ID: <3DA3F23C.50207@superbug.demon.co.uk> (raw)
In-Reply-To: s5h7kgs3lud.wl@alsa2.suse.de
Takashi Iwai wrote:
>At Fri, 04 Oct 2002 01:10:50 +1000,
>James Courtier-Dutton wrote:
>
>
>>Hello
>>I have searched the web to find the specs on this chip. No Luck.
>>What I have found is that it is a Yamaha OPL3-SA2 or YMF711.
>>Which playback rates does it support ?
>>
>>
>
>the dma engine of opl3sax is actually cs4231-compatible.
>thus it supports the following sample rates:
> 5510, 6620, 8000, 9600, 11025, 16000, 18900, 22050,
> 27042, 32000, 33075, 37800, 44100, 48000
>
>
>
>>I find that anything above 32k causes jittery playback.
>>
>>
>
>most likely you hit a bug ;)
>
>how is the symptom exactly? repeated (stutter) sounds?
>
>
>what i heard about this chip is that the pcm is not audible until a
>pcm mixer element is modified at each open.
>but it looks like a different problem...
>
>
>ciao,
>
>Takashi
>
>
>
>
I think the problem is that the sound buffer is filled by the
application, but then on a slow PC, the CPU is locked into doing
something with the X display (XV video images), and the transfer inside
alsa-lib from buffer to sound card does not get CPU time. So, basically
samples are lost.
So, if I was to send 3 groups of samples to the sound card, A,B, C.
The alsa-lib buffer is then filled with A,B,C, but the sound hardware
grabs a period, so takes A and plays it, but when the sound card comes
to get B, it does not have the CPU time, so the sound card just plays
silence, when the sound card gets CPU time, it then plays B, then plays
C, but as it played B and C late, my application tries to resync and
drops D and then sends E to the sound card.
Is there any reports in alsa to report missed interrupts to the
application ?
I understand that an "underrun" is when the interrupt gets CPU time, but
the application is not up to speed, but what if there is too long a
delay between the sound card signalling an interrupt, and the interrupt
routine actually being run ? The sound card hardware will not get the
samples it needs, but "underrun/xrun" is not sent back to the app.
Cheers
James
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
prev parent reply other threads:[~2002-10-09 9:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-03 15:10 OPL3-SA2/3 PCM Playback rates? James Courtier-Dutton
2002-10-08 17:02 ` Takashi Iwai
2002-10-09 9:09 ` James Courtier-Dutton [this message]
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=3DA3F23C.50207@superbug.demon.co.uk \
--to=james@superbug.demon.co.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=tiwai@suse.de \
/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.