All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.