Hi,
what about the game you've talked about ?)
I will working on the "3D-game" audio part the next two weeks. If I have time, I will write some notes about my recent tests.
a) you shouldn't dynamically create abstractions while dsp is running, as it slows down significantly.
I would have liked to hear it before... May be I missed a message.
How much is your "significantly" ? Do you have taken measures to see what happens whith 10 audio objects, 100 or 1000 ?
b) do [; pd dsp 0; pd dsp 1( right after your creation to fix the dsp-graph
But audio clics may occur for all sounds, not just for the new one, right ? Could we do whithout a [line~] object to turn on/off sounds smootly and avoid audio clics ?
If we handle all sounds with a [line~]: 1 - stop all sounds smoothly (10 msec) with a GLOBAL send message 2 - wait 10 msec 3 - dsp 0 4 - create the new audio abstractions 5 - dsp 1 6 - turn on all sounds smoothly (10 msec) with a GLOBAL send message
Does it sound good ? We have a 20 msec "hole" of sounds. I'm sure that it may be perceptible. Imagine a sound of a bird turned off and on in 20 msec. If we take 5 msec instead of 10 msec ...
Cheers,
Jerome
Le 18/08/2011 20:07, abel.jerome@free.fr a écrit :
Hi,
Salut Jérôme,
a) you shouldn't dynamically create abstractions while dsp is running, as it slows down significantly.
I would have liked to hear it before... May be I missed a message.
How much is your "significantly" ?
depends on the machine as usual and also the niceness of your RT settings on a Linux box
But audio clics may occur for all sounds, not just for the new one, right ? Could we do whithout a [line~] object to turn on/off sounds smootly and avoid audio clics ?
Why not try [switch~] inside of your abs?
La bise aux cagoles, OH
On 08/18/2011 08:07 PM, abel.jerome@free.fr wrote:
Hi,
what about the game you've talked about ?)
I will working on the "3D-game" audio part the next two weeks. If I have time, I will write some notes about my recent tests.
a) you shouldn't dynamically create abstractions while dsp is running, as it slows down significantly.
I would have liked to hear it before... May be I missed a message.
most likely. not in this thread but the issue has been discussed several times.
How much is your "significantly" ? Do you have taken measures to see what happens whith 10 audio objects, 100 or 1000 ?
significantly means:
if dsp is on, and you dyamincally create 10 objects in one go (in zero logical time), then the dsp graph will be re-calculated 10 times.
if you turn dsp off, then dynamically create 10 objects as before, then no dsp graph will be evaluated until you turn dsp on again, summing up to exactly 1 time.
furthermore, it guarantees that the entire DSP graph is calculated and not only parts of it (because of buggy implementations)
b) do [; pd dsp 0; pd dsp 1( right after your creation to fix the dsp-graph
But audio clics may occur for all sounds, not just for the new one, right ?
no, this is wrong. (at least not, if you computer is fast enough to calculate the DSP-graph within the buffertime). however, you will have the same problem if you do any weird "cut" clicks.
Could we do whithout a [line~] object to turn on/off sounds smootly and avoid audio clics ?
If we handle all sounds with a [line~]: 1 - stop all sounds smoothly (10 msec) with a GLOBAL send message 2 - wait 10 msec 3 - dsp 0 4 - create the new audio abstractions 5 - dsp 1 6 - turn on all sounds smoothly (10 msec) with a GLOBAL send message
Does it sound good ?
no. or rather: depends on what you need; if you can live with a 20 ms inconsistency. for many applications though, this 20ms fadeout-fadein will be almost equally annoying as a click.
We have a 20 msec "hole" of sounds. I'm sure that it may be perceptible.
it _will_ be perceptible.
those clicks have been discussed a number of times on this list (please search the archives).
mgfasdr IOhannes
2011/8/19 IOhannes zmölnig zmoelnig@iem.at
On 08/18/2011 08:07 PM, abel.jerome@free.fr wrote:
b) do [; pd dsp 0; pd dsp 1( right after your creation to fix the
dsp-graph
But audio clics may occur for all sounds, not just for the new one, right
?
no, this is wrong. (at least not, if you computer is fast enough to calculate the DSP-graph within the buffertime).
Good to know. I've done my tests with my intern laptop sound card...
however, you will have the same problem if you do any weird "cut" clicks.
... but it's with the same sound card I don't have the same problem with weird "cut" clicks.
To be continued...
Cheers.
01ivier
mgfasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/19/2011 10:18 AM, IOhannes zmölnig wrote: ...
if dsp is on, and you dyamincally create 10 objects in one go (in zero logical time), then the dsp graph will be re-calculated 10 times.
if you turn dsp off, then dynamically create 10 objects as before, then no dsp graph will be evaluated until you turn dsp on again, summing up to exactly 1 time.
plus closing and reopening of the audio driver, which is induced by `pd dsp', and not by object creation. So it is like sometimes it is better to forget about an itching place, rather than scratch it.
Krzysztof
On 08/19/2011 03:09 PM, Krzysztof Czaja wrote:
plus closing and reopening of the audio driver, which is induced by `pd dsp', and not by object creation. So it is like sometimes it is better to forget about an itching place, rather than scratch it.
ouch, your point.
mfgasdr IOhannes
PS: any chance to get more or less int a public repository?
-
abel.jerome＠free.fr -
IOhannes zmölnig -
Krzysztof Czaja -
Oli44 -
Olivier B