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
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'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
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
I don't have a modern ASIO soundcard. (m-audio fast track pro, tascam us-122)
Pd controls my blocksize (ASIO buffer).
On fast track pro I can go to 6ms IO, (with block size 256)
[adc~] l [dac~]
What is MixControl ?
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Christof Ressi christof.ressi@gmx.at Sent: Tuesday, February 21, 2017 1:16 AM To: pd-list Subject: Re: [PD] Pd + ASIO
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
Pd controls my blocksize (ASIO buffer).
Interesting. And your soundcard can't handle multiple streams, like playing sound from two or more instances of Pd, right? I'm curious.
On fast track pro I can go to 6ms IO, (with block size 256)
that's nice :-)
What is MixControl ?
Focusrite software for the Scarlett interface. Similar to RME's TotalMix.
Gesendet: Dienstag, 21. Februar 2017 um 02:35 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
I don't have a modern ASIO soundcard. (m-audio fast track pro, tascam us-122) Pd controls my blocksize (ASIO buffer). On fast track pro I can go to 6ms IO, (with block size 256) [adc~] l [dac~] What is MixControl ?
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Christof Ressi christof.ressi@gmx.at Sent: Tuesday, February 21, 2017 1:16 AM To: pd-list Subject: Re: [PD] Pd + ASIO 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%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd controls my blocksize (ASIO buffer).
Interesting. And your soundcard can't handle multiple streams, like playing sound from two or more instances of Pd, right? I'm curious.
Thats right, only one app (not necessary Pd) can access the soundcard via ASIO.
Just for testing:
Install asio4all and use it (if possible) with your built-in soundcard.
You will see Pd controls the asio4all buffer. You can move the slider but is useless, along the line of that slider there's a zone with a different color. That`s what is controled/set & used by Pd. Iirc.
It could be that your trouble is related to that Focusrite has a different implementation on this.
Does other ASIO software can control your focusrite?
Mensaje telepatico asistido por maquinas.
From: Christof Ressi christof.ressi@gmx.at Sent: Tuesday, February 21, 2017 1:46 AM To: Lucas Cordiviola Cc: pd-list Subject: Aw: Re: [PD] Pd + ASIO
Pd controls my blocksize (ASIO buffer).
Interesting. And your soundcard can't handle multiple streams, like playing sound from two or more instances of Pd, right? I'm curious.
On fast track pro I can go to 6ms IO, (with block size 256)
that's nice :-)
What is MixControl ?
Focusrite software for the Scarlett interface. Similar to RME's TotalMix.
list[https://lists.puredata.info/listinfo/pd-listhttps://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
Thats right, only one app (not necessary Pd) can access the soundcard via ASIO.
Ok, thanks!
Does other ASIO software can control your focusrite?
No, at least not in the way you're used to. As I've said, modern quality audio interfaces automatically come with multi-client ASIO drivers which means that several apps can access the device simultaneously. Before that, a single app had total control over the sound card via the ASIO driver (and could therefore set the latency directly, as you observed with your audio interfaces) but apparently that's not true any more. It wouldn't work that way because each app can request a different buffersize.
I'm curious if there are users on the list who have experiences with *multi-client* ASIO devices + Pd? I'll make some tests with different audio interfaces and collect the results.
Gesendet: Dienstag, 21. Februar 2017 um 04:57 Uhr Von: "Lucas Cordiviola" lucarda27@hotmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at Betreff: Re: Re: [PD] Pd + ASIO
Pd controls my blocksize (ASIO buffer).
Interesting. And your soundcard can't handle multiple streams, like playing sound from two or more instances of Pd, right? I'm curious.
Thats right, only one app (not necessary Pd) can access the soundcard via ASIO. Just for testing: Install asio4all and use it (if possible) with your built-in soundcard. You will see Pd controls the asio4all buffer. You can move the slider but is useless, along the line of that slider there's a zone with a different color. That`s what is controled/set & used by Pd. Iirc. It could be that your trouble is related to that Focusrite has a different implementation on this. Does other ASIO software can control your focusrite?
Mensaje telepatico asistido por maquinas.
From: Christof Ressi christof.ressi@gmx.at Sent: Tuesday, February 21, 2017 1:46 AM To: Lucas Cordiviola Cc: pd-list Subject: Aw: Re: [PD] Pd + ASIO
Pd controls my blocksize (ASIO buffer).
Interesting. And your soundcard can't handle multiple streams, like playing sound from two or more instances of Pd, right? I'm curious.
On fast track pro I can go to 6ms IO, (with block size 256)
that's nice :-)
What is MixControl ?
Focusrite software for the Scarlett interface. Similar to RME's TotalMix.
list[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
-
Christof Ressi -
Lucas Cordiviola