I really do think now that the buffersize in the ASIO driver settings determines the minimum number of samples an audio stream can request from the device. It would make sense and would also explain my experiences with RtAudio. I might be wrong, though.

Usually, I can set the latency in MixControl to the lowest possible value and let every app request the buffersize it actually needs (e.g. 1024 or 2048 when mixing large projects in Reaper). Somehow that doesn't work with Pd. I have to go for a relatively high latency in MixControl and the 'blocksize' (= buffersize) setting in Pd doesn't have much effect on top of that...


> Gesendet: Dienstag, 21. Februar 2017 um 01:46 Uhr
> Von: "Christof Ressi" <christof.ressi@gmx.at>
> An: "Lucas Cordiviola" <lucarda27@hotmail.com>
> Cc: pd-list <pd-list@iem.at>
> Betreff: Re: [PD] Pd + ASIO
>
> > Pd's block size in preferences controls the actual ASIO buffer for the sound card.
>
> Actually it does not.
>
> I've noticed in the past that you can directly control the ASIO blocksize via Pd for asio4all but this doesn't work with some/many/most(?) professional soundcards. I guess the reason why it works with asio4all is that you can only have a single ASIO stream. Professional modern ASIO devices, however, can handle several streams, each requesting their own buffersize. On the other hand, the ASIO driver setting does have an effect in a way that it dictates which buffer sizes will work and the API methods for opening a stream will negotiate with the soundcard for the best solution. At least, that's how I understood it from my own experience and reading the RtAudio and portaudio docs. 
>
> It would be helpful if I could at least add some debugging code to Pd to check the actual buffersize Pd is requesting and getting from the soundcard. But for that I have to wait till I can build Pd with MinGW...
>
> Right now, I can get reliable results with the following settings: 10ms latency in MixControl, 64 samples 'blocksize' (buffersize) in Pd and 20ms Pd latency. It's acceptable but I know that Pd can achieve a much better performance on other systems/setups. Normally I'd say it's Windows but playing around with RtAudio showed me that low latency realtime audio *is* possible even on Windows.
>
>
>  
>  
>
> Gesendet: Dienstag, 21. Februar 2017 um 00:42 Uhr
> Von: "Lucas Cordiviola" <lucarda27@hotmail.com>
> An: "Christof Ressi" <christof.ressi@gmx.at>, pd-list <pd-list@iem.at>
> Betreff: Re: [PD] Pd + ASIO
>
>  
> May be this helps.
>  
> Pd's block size in preferences controls the actual ASIO buffer for the sound card.
>  
> For more clarity on this use asio4all, when changing Pd's block size that reflects on the actual ASIO used buffer.
>  
> (Pd's pref blocksize is ONLY for ASIO and has nothing to do with your patch blocksize)
>  
> Try Pd's pref blocksize to 256.
>  
> After that check the current scarlett ms numbers.
>  
> Did it change? And is now controled by Pd?
>  
> This may require restarting Pd and possible restart of the soundcard.
>  
>  
>  
>
> Mensaje telepatico asistido por maquinas. 
>
> ------------------------------------------------------------
>
> From: Pd-list <pd-list-bounces@lists.iem.at> on behalf of Christof Ressi <christof.ressi@gmx.at>
> Sent: Monday, February 20, 2017 11:24 PM
> To: pd-list
> Subject: [PD] Pd + ASIO
>  
> Hi,
>
> I've started porting a Pd project to C++ and I'm working with the RtAudio library to interface with my soundcard (Focusrite Scarlett 6i6). There I noticed that I get a *much* better performance than in Pd regarding audio IO. I can play several thousand sawtooth tones with a blocksize of 1 and a buffer size of 64 samples (~ 1ms in my ASIO settings) and still get a clean and stable output on my Lenovo L440 laptop. In Pd, on the other hand, I get dropouts on a single testtone when I put the ASIO latency down to the same value. The 'delay' setting in Pd is 20ms - which is quite generous - so for me it's clearly an IO problem. I don't know if the reason is Pd or rather portaudio, though.
>
> The Focusrite Scarlett interfaces are 'special' in a way that they only let you choose a latency in ms, which is pretty annoying in some circumstances.
>
> I noticed some things when playing around with RtAudio:
>
> If you requeste a buffersize (via RtAudio::openStream) which is *smaller* than the current latency set in Scarlett MixControl (in ms), it will pick that latency instead and you get strange buffersizes like 442 samples (~ 10 ms). If your requested buffersize is *greater*, you get this very buffersize.
>
> Regarding performance: choosing 1 ms in MixControl and requesting 64 samples via RtAudio works beautifully, but in Pd I cannot achieve any decent and stable IO with the same latency setting.
>
> I don't know if I'd go so far and say that ASIO is broken in Pd, but on some soundcards it's definitely not working well. I have the suspicion that Scarlett's odd latency setting might be the culprit. But I remember that I also had bad results with an RME babyface. I have to check again, though.
>
> Does anyone have more insight in how Pd communicates with portaudio when using ASIO? How is the ASIO buffersize being handled? What are your experiences with latency settings for Pd + ASIO?
>
> Christof
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list