[Sc-devel] scsynth -L option

Christopher Frauenberger frauenberger at iem.at
Thu Mar 6 04:39:05 PST 2008 

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 at create.ucsb.edu
>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Sc-devel mailing list
>>>>>>> Sc-devel at create.ucsb.edu
>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Sc-devel mailing list
>>>>>> Sc-devel at create.ucsb.edu
>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sc-devel mailing list
>>>>> Sc-devel at create.ucsb.edu
>>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>>>
>>>> _______________________________________________
>>>> Sc-devel mailing list
>>>> Sc-devel at create.ucsb.edu
>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>>>
>>>
>>> _______________________________________________
>>> Sc-devel mailing list
>>> Sc-devel at create.ucsb.edu
>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>
>> _______________________________________________
>> Sc-devel mailing list
>> Sc-devel at create.ucsb.edu
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

More information about the Sc-devel mailing list