[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] scsynth -L option



Hi Ron,

maybe an example helps: my Windows machine has a crapy AC97 soundcard with standard WMME drivers. With a hardware Buffer size of 64 samples and a sample rate of 44.1k the driver suggests a latency of 0.23 sec. If you push this down below 0.05 sec you will have nothing but glitches.

The theoretical minimal latency of 64 * 2 (stereo) / 44100 = 0.0029 sec is simply not achievable with WMME drivers. Running the same hardware with ASIO drivers, you get far lower suggested latencies.

PortAudio tries to estimate safe latency values for the hardware/ driver combination, but also provides the user with the possibility to override this suggestion (for which the -L switch was meant). But I am now convinced that we should go with the PortAudio default and make people using different drivers that can safely play sound with lower latency if they need it.

Chris

On 6 Mar 2008, at 12:26, ronald kuivila wrote:

Hi Chris,

I don't understand,  can't you just insert something like

	Server.default.options.hardwareBufferSize = 0.2 * 44100	// latency
of 0.2 seconds

before booting the server ?

RJK

On Mar 5, 2008, at 5:55 PM, Christopher Frauenberger wrote:

Ron,

done exactly that, but it turns out that this is only the minimal
latency that would be possible, but for most drivers a far too
optimistic setting - i.e. causes many implementations to choke
badly...

Chris

On 5 Mar 2008, at 18:26, ronald kuivila wrote:

Hi Chris,

  I believe all you need to do is crank up the hardware buffer size
in ServerOptions.
Take that value multiply by 1000 and divide by the sampling rate and
use that
as suggestedLatency.


RJK

On Mar 5, 2008, at 12:46 PM, Christopher Frauenberger wrote:

Hi,

unfortunately this is deprecated and replaced by the
suggestedLatency
property of PaStreams (the one I was fiddling around with
before...).
I tried setting it to a meaningful value such as

numBufs * numSamples / sampleRate

but the underlying implementations are really so different that this
results in a far to small latency most of the times. The -L switch
would have allowed people to push their systems and go as low as
possible, but thats just trial and error really.

I suspect we just have to leave it as it is and go with the lowest
latency suggested by the api. If people have problems with that,
they
need to find different drivers for their hardware. (ASIO, DSound).

Chris

On 4 Mar 2008, at 20:31, ronald kuivila wrote:

Hi Chris,

I just took a look at

	http://www.portaudio.com/docs/latency.html

which is what you need to consult. It looks like what you actually
want to do is compute the latency in milliseconds
(100 * bufferSize/samplingRate) and set the environment variable
PA_MIN_LATENCY_MSEC to that value.
You don't need a new flag, you just need to use the existing
information to tell PortAudio how to do its stuff.

The page suggests a number of system tweaks for XP to improve
performance.

Here are some relevant quotes from that page:

"The only delay that PortAudio can control is the total length of
its buffers. The Pa_OpenStream() call takes two parameters:
numBuffers and framesPerBuffer. The latency is also affected by the
sample rate which we will call framesPerSecond....The latency in
milliseconds due to this buffering  is:
latency_msec = 1000 * numBuffers * framesPerBuffer /
framesPerSecond
This is not the total latency, as we have seen, but it is the part
we can control."

"On some systems you can override the PortAudio minimum if you know
your system can handle a lower value. You do this by setting an
environment variable called PA_MIN_LATENCY_MSEC which is read by
PortAudio when it starts up. This is supported on the PortAudio
implementations for Windows MME, Windows DirectSound, and Unix
OSS."


Cheers,

RJK


On Mar 4, 2008, at 12:08 PM, Chris Frauenberger wrote:

Hello,

quite frankly, I dont know exactly what the parameter does. As
portaudio
is a platform independent API it is up to the various
implementation to
put this value into context. It is, however, not the hardware
buffer
size (which can be assigened separately).

The proposed -L switch would provide access to the PaTime
PaStreamParameters::suggestedLatency (from the docs):

The desired latency in seconds. Where practical, implementations
should
configure their latency based on these parameters, otherwise they
may
choose the closest viable latency instead. ... Actual latency
values for
an open stream may be retrieved using the inputLatency and
outputLatency
fields of the PaStreamInfo structure returned by Pa_GetStreamInfo
().

For Windows MME drivers the default suggested latency is up to 0.2
sec
while the buffer size is still 64 samples. Maybe Ross can shed
some
light on this.

Thanks
Chris

ronald kuivila wrote:
Hi all,

Maybe a little explanation is in order. There are several
different
issues parameters involved in system latency:

	blockSize				-z option
	hardware buffer size 		-Z option
Server object latency language side parameter that can be tuned

   Right now, if the hardware buffer size is bigger than
blockSize,
untimestamped messages are processed  on the next hardware
buffer rather than the next sample block.  (This is the issue
Alberto
mentioned on the list a while ago.)

   The Server object latency imposes a delay that should be
larger
than the largest delay associated with hardware buffer size and
UDP
transmission.
This will guarantee accurate timing. It can be altered without
rebooting the server.

RJK


On Mar 4, 2008, at 5:01 AM, Stefan Kersten wrote:

On 29.02.2008, at 14:59, Christopher Frauenberger wrote:
now that version 3.2 is launched, I would commit the change
proposed.
It essentially introduces a -L switch to scsynth when compiled
with
port-audio to specify a preferred latency. This is important as
the
suggested latency (especially on Windows) is sometimes really
high
(0.2 sec) and could be reduced by the user for time-critical
things
through the server options.
shouldn't the hardware buffer size -Z option be used for
specifying
the latency? scsynth seems to be competing already with
csound in
terms of command line options ;)

<sk>

_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel