Well, the concert was a success. The dynamic notation system worked perfectly (almost) but the audio patch had some problems. Video will be posted on my blog soon, but I want to know about the audio patch.
It takes incoming sound, records it into a buffer, and dynamically creates [table] objects for each event in a pd subpatch, then copies the data from the input buffer into each table when each event is finished (i.e. when the next event starts) using the maxlib [arraycopy] object. Events are logged using [bonk~].
I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream? If so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it) and 2. if so, can pd -nogui sort it out?
Ed Metastudio 4 for Pure Data - coming soon! Metastudio 3 still available at http://sharktracks.co.uk/puredata
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-02 01:00, Ed Kelly wrote:
I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream? If so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it) and 2. if so, can pd -nogui sort it out?
given that you most likely do all the dynamic creation inside a closed canvas/window, the gui can be ruled out: so, no 0.43 won't fix your problems for you, nor will -nogui [1]
the problem most likely comes from the DSP graph being continuously rebuilt. the only things you can do for now is:
- try to reduce rebuilding of the DSP graph as much as possible.
needeless to say that you shouldn't dynamically create objects that are not needed. more interesting is that e.g. creating 3 objects while audio is running, will re-caculate the DSP graph 3 times. even if this happens in 0 logical time. so i you know you are going to schedule several dynamically created objects "at once", turn audio off before and turn it on again after you do the actual creation.
- try to get the DSP graph building into a separate thread.
well, this involves pd~ or the like....
fgmasdr IOhannes
[1] btw, it's usually really easy to check things: e.g. running your patch with "-nogui" and see whether you get dropouts might take about the same time as (you) asking on this list, (me) answering on this list and (you) reading the answer - not counting the delay due to amil-servers and the like. anyhow.
On 2011-02-02 01:00, Ed Kelly wrote:
I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream?
If
so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it)
and 2. if so, can pd -nogui sort it out?
the problem most likely comes from the DSP graph being continuously rebuilt. the only things you can do for now is:
- try to reduce rebuilding of the DSP graph as much as possible.
needeless to say that you shouldn't dynamically create objects that are not needed. more interesting is that e.g. creating 3 objects while audio is running, will re-caculate the DSP graph 3 times. even if this happens in 0 logical time. so i you know you are going to schedule several dynamically created objects "at once", turn audio off before and turn it on again after you do the actual creation.
Dammit! Only one at a time, but they are tables of perhaps 300000 points. Then I copy data from the input buffer into the table. It has to be running with the audio, since the audio is being re-mixed in real time. Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be OK if I was using only output, but the whole point is to live-sample the input. The mic input on my laptop is really crappy.
- try to get the DSP graph building into a separate thread.
well, this involves pd~ or the like....
Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM
- but I see the new version of Inscore supports PD, so all my work over the
last 6 months has been for nothing. Pah!
Ed
fgmasdr IOhannes
[1] btw, it's usually really easy to check things: e.g. running your patch with "-nogui" and see whether you get dropouts might take about the same time as (you) asking on this list, (me) answering on this list and (you) reading the answer - not counting the delay due to amil-servers and the like. anyhow.
Ed, I don't know if anecdotal confirmation will help you here, or just make you more frustrated, but I've noticed that I get more dropouts using Jack as opposed to portaudio (OS X) for the exact same processor-load. This has caused me to switch back to portaudio. Does anybody have any idea why this might be?
Phil Stone www.pkstonemusic.com
On 2/2/11 3:25 PM, Ed Kelly wrote:
On 2011-02-02 01:00, Ed Kelly wrote:
I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream?
If
so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it) and 2. if so, can pd -nogui sort it out?
the problem most likely comes from the DSP graph being continuously rebuilt. the only things you can do for now is:
- try to reduce rebuilding of the DSP graph as much as possible.
needeless to say that you shouldn't dynamically create objects that are not needed. more interesting is that e.g. creating 3 objects while audio is running, will re-caculate the DSP graph 3 times. even if this happens in 0 logical time. so i you know you are going to schedule several dynamically created objects "at once", turn audio off before and turn it on again after you do the actual creation.
Dammit! Only one at a time, but they are tables of perhaps 300000 points. Then I copy data from the input buffer into the table. It has to be running with the audio, since the audio is being re-mixed in real time. Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be OK if I was using only output, but the whole point is to live-sample the input. The mic input on my laptop is really crappy.
- try to get the DSP graph building into a separate thread.
well, this involves pd~ or the like....
Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM
- but I see the new version of Inscore supports PD, so all my work over the
last 6 months has been for nothing. Pah!
Ed
fgmasdr IOhannes
[1] btw, it's usually really easy to check things: e.g. running your patch with "-nogui" and see whether you get dropouts might take about the same time as (you) asking on this list, (me) answering on this list and (you) reading the answer - not counting the delay due to amil-servers and the like. anyhow. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1JKCQACgkQkX2Xpv6ydvQzfQCgsvmL0cevgXGPbL1oZW4keMcu diwAoJaN6Pvheh261jAZwzr2CpJ78ypV =z/KF -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2011-02-02 at 23:25 +0000, Ed Kelly wrote:
On 2011-02-02 01:00, Ed Kelly wrote:
I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream?
If
so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it)
and 2. if so, can pd -nogui sort it out?
the problem most likely comes from the DSP graph being continuously rebuilt. the only things you can do for now is:
- try to reduce rebuilding of the DSP graph as much as possible.
needeless to say that you shouldn't dynamically create objects that are not needed. more interesting is that e.g. creating 3 objects while audio is running, will re-caculate the DSP graph 3 times. even if this happens in 0 logical time. so i you know you are going to schedule several dynamically created objects "at once", turn audio off before and turn it on again after you do the actual creation.
Dammit! Only one at a time, but they are tables of perhaps 300000 points. Then I copy data from the input buffer into the table.
In your situation I'd try to do everything that doesn't necessarily need to happen in 0 logical time to extend to > 0 logical time. Unless you really need the new tables immediately after the buffer was filled, I'd suggest to copy them over 'slowly'. One approach once mentioned by Miller Puckette is to do array copying by doing it in the audio domain within an upsampled sub-patch. This would make DSP drop-outs during array copying much less likely.
It has to be running with the audio, since the audio is being re-mixed in real time.
Wrong. Dynamic creation happens in 0 logical time. Now let's consider a case where you dynamically create several objects in one go. After every single object the DSP graph is recompiled. The real time this process takes is quite high. Now if you'd first turn off DSP, create all necessary objects dynamically and then turn DSP on again, the DSP graph is recompiled once and the real time this takes is much shorter. If you're lucky, it will be so short (shorter than your current audio buffer setting), that you don't even notice a drop out.
Just to make myself more clear: It's perfectly possible to turn DSP off and on again in 0 logical time without noticing it at all, even when there is some audio processing going on.
Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be OK if I was using only output, but the whole point is to live-sample the input. The mic input on my laptop is really crappy.
- try to get the DSP graph building into a separate thread.
well, this involves pd~ or the like....
Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM
- but I see the new version of Inscore supports PD, so all my work over the
last 6 months has been for nothing.
I wouldn't be too sure about that. Try to figure out what needs to really happen in 0 logical time, since most often the problems of audio drop outs is that Pd is requested too much to compute in 0 time. Try to distribute as much as possible over time, so that as many things as possible happen continuously and as little things as possible need to be calculated instantly.
Roman
On Thu, 3 Feb 2011, Roman Haefeli wrote:
In your situation I'd try to do everything that doesn't necessarily need to happen in 0 logical time to extend to > 0 logical time. Unless you really need the new tables immediately after the buffer was filled, I'd suggest to copy them over 'slowly'.
BTW, merely creating a table is taking a lot of time, especially as the table's a_vec is allocated using getbytes(), and getbytes() takes the time to fill the whole 300000*4 bytes (or 300000*8 bytes) with carefully polished zeroes.
In addition, OSX's allocator for large chunks of memory does a mmap() just on linux, but unlike on linux, mmapping new memory on osx is annoyingly slow (perhaps also another kind of zero-polishing). However, I can't tell you whether this happens at the time of mmap(), or at the time of starting to write in a new page of RAM (a 4k block), but this does not matter, as getbytes() forces all pages to spring into existence at the same time.
One approach once mentioned by Miller Puckette is to do array copying by doing it in the audio domain within an upsampled sub-patch. This would make DSP drop-outs during array copying much less likely.
The table is still being cleared anyway, once or twice, before it's filled with the real content, and it uses up that much of space in the SRAM too (cache). This happens every time you create or resize an array.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Only one at a time, but they are tables of perhaps 300000 points. Then I copy
data from the input buffer into the table.
In your situation I'd try to do everything that doesn't necessarily need to happen in 0 logical time to extend to > 0 logical time. Unless you really need the new tables immediately after the buffer was filled, I'd suggest to copy them over 'slowly'. One approach once mentioned by Miller Puckette is to do array copying by doing it in the audio domain within an upsampled sub-patch. This would make DSP drop-outs during array copying much less likely.
Hmmm...perhaps it would be better, to play them into another [tabwrite~]. Its just that I wanted them immediately an event ended so that I could do reversed playback of an event just as the next event begins.
It has to be running with the audio, since the audio is being re-mixed in
real
time.
Wrong. Dynamic creation happens in 0 logical time. Now let's consider a case where you dynamically create several objects in one go. After every single object the DSP graph is recompiled. The real time this process takes is quite high. Now if you'd first turn off DSP, create all necessary objects dynamically and then turn DSP on again, the DSP graph is recompiled once and the real time this takes is much shorter. If you're lucky, it will be so short (shorter than your current audio buffer setting), that you don't even notice a drop out.
Just to make myself more clear: It's perfectly possible to turn DSP off and on again in 0 logical time without noticing it at all, even when there is some audio processing going on.
WHOA! I did not think of that. I'll try it.
Ed
Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be
OK if I was using only output, but the whole point is to live-sample the input.
The mic input on my laptop is really crappy.
- try to get the DSP graph building into a separate thread.
well, this involves pd~ or the like....
Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM
- but I see the new version of Inscore supports PD, so all my work over the
last 6 months has been for nothing.
I wouldn't be too sure about that. Try to figure out what needs to really happen in 0 logical time, since most often the problems of audio drop outs is that Pd is requested too much to compute in 0 time. Try to distribute as much as possible over time, so that as many things as possible happen continuously and as little things as possible need to be calculated instantly.
Roman
On Wed, 2 Feb 2011, Ed Kelly wrote:
Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM - but I see the new version of Inscore supports PD, so all my work over the last 6 months has been for nothing. Pah!
Your tool surely has some advantages over Inscore.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Ed Kelly -
IOhannes m zmoelnig -
Mathieu Bouchard -
Phil Stone -
Roman Haefeli