Dear List!
I have a problem, where hope the solution is so easy as it is complicated for me to find a solution:
When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream.
I tryed to switch off the patch within the array for the moment of loading - but I get the same result.
Is there a way to avoid this dropout?
I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8
Thanks a lot for any help and with best regards,
Sebastian
On 31/10/11 17:37, Sebastian Hanusa wrote:
Dear List!
I have a problem, where hope the solution is so easy as it is complicated for me to find a solution:
When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream.
I tryed to switch off the patch within the array for the moment of loading - but I get the same result.
Is there a way to avoid this dropout?
If you need the sample "instantly now", then probably not (you could try increasing the pd buffer size which adds latency, but that's no guarantee).
But, if you need it "quite soon but I can wait a little" see also:
http://lists.puredata.info/pipermail/pd-list/2008-05/062310.html
and similar mailing list archive threads.
I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8
Thanks a lot for any help and with best regards,
Sebastian
Claude
[soundfiler] will always interrupt the audio stream.
What I have done before was to stream the soundfile into a table with [readsf~]. You can upsample the subpatch with [block~] or [switch~] so it reads faster than realtime.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Sebastian Hanusa Gesendet: Montag, 31. Oktober 2011 18:37 An: pd-list@iem.at Betreff: [PD] Interruption of audio / Loading sound into array
Dear List!
I have a problem, where hope the solution is so easy as it is complicated for me to find a solution:
When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream.
I tryed to switch off the patch within the array for the moment of loading - but I get the same result.
Is there a way to avoid this dropout?
I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8
Thanks a lot for any help and with best regards,
Sebastian
Hi,
This might just be a graphics related problem. Just disable the graphical representation of the arrays (I'm not in front of Pd right now but If I remeber well, it's just a matter of clicking on the arrays and unchecking the "graph on parent" box). I had the very same problem under Win XP, it solved everything.
Hope this helps.
D.S
http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/
From: ingo@miamiwave.com To: sebastian.hanusa@gmx.de; pd-list@iem.at Date: Mon, 31 Oct 2011 19:24:20 +0100 Subject: Re: [PD] Interruption of audio / Loading sound into array
[soundfiler] will always interrupt the audio stream.
What I have done before was to stream the soundfile into a table with [readsf~]. You can upsample the subpatch with [block~] or [switch~] so it reads faster than realtime.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Sebastian Hanusa Gesendet: Montag, 31. Oktober 2011 18:37 An: pd-list@iem.at Betreff: [PD] Interruption of audio / Loading sound into array
Dear List!
I have a problem, where hope the solution is so easy as it is complicated for me to find a solution:
When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream.
I tryed to switch off the patch within the array for the moment of loading - but I get the same result.
Is there a way to avoid this dropout?
I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8
Thanks a lot for any help and with best regards,
Sebastian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This might just be a graphics related problem.
It's not!
Ingo
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von David Schaffer Gesendet: Donnerstag, 3. November 2011 12:31 An: pd list Betreff: Re: [PD] Interruption of audio / Loading sound into array
Hi,
This might just be a graphics related problem. Just disable the graphical representation of the arrays (I'm not in front of Pd right now but If I remeber well, it's just a matter of clicking on the arrays and unchecking the "graph on parent" box). I had the very same problem under Win XP, it solved everything.
Hope this helps.
D.S http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/
From: ingo@miamiwave.com To: sebastian.hanusa@gmx.de; pd-list@iem.at Date: Mon, 31 Oct 2011 19:24:20 +0100 Subject: Re: [PD] Interruption of audio / Loading sound into array
[soundfiler] will always interrupt the audio stream.
What I have done before was to stream the soundfile into a table with [readsf~]. You can upsample the subpatch with [block~] or [switch~] so it reads faster than realtime.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag
von
Sebastian Hanusa Gesendet: Montag, 31. Oktober 2011 18:37 An: pd-list@iem.at Betreff: [PD] Interruption of audio / Loading sound into array
Dear List!
I have a problem, where hope the solution is so easy as it is complicated for me to find a solution:
When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream.
I tryed to switch off the patch within the array for the moment of loading - but I get the same result.
Is there a way to avoid this dropout?
I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8
Thanks a lot for any help and with best regards,
Sebastian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Nov 3, 2011, at 3:16 PM, Charles Goyard wrote:
Ingo wrote:
This might just be a graphics related problem.
It's not!
it's more related to pd being monothreaded. It forces you to do the hard scheduling work.
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel. And you had to do nothing to make sure that they run in parallel, don't block each other, sync up, etc.
.hc
kill your television
Le 2011-11-03 à 15:32:00, Hans-Christoph Steiner a écrit :
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel. And you had to do nothing to make sure that they run in parallel, don't block each other, sync up, etc.
Are you talking about Pd ?
(you surely are not)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 3, 2011, at 3:44 PM, Mathieu Bouchard wrote:
Le 2011-11-03 à 15:32:00, Hans-Christoph Steiner a écrit :
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel. And you had to do nothing to make sure that they run in parallel, don't block each other, sync up, etc.
Are you talking about Pd ?
(you surely are not)
It is only recently that threads started to run at actually the same time, and that is still not a guaranteed thing. So yes, we experience apps running "at the same time" but for the most part, there is a lot of time slicing involved, just like Pd. There is only one arm on the hard disk heads still, for example.
.hc
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
Le 2011-11-03 à 15:52:00, Hans-Christoph Steiner a écrit :
On Nov 3, 2011, at 3:44 PM, Mathieu Bouchard wrote:
Le 2011-11-03 à 15:32:00, Hans-Christoph Steiner a écrit :
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel. And you had to do nothing to make sure that they run in parallel, don't block each other, sync up, etc.
Are you talking about Pd ? (you surely are not)
It is only recently that threads started to run at actually the same time, and that is still not a guaranteed thing. So yes, we experience apps running "at the same time" but for the most part, there is a lot of time slicing involved, just like Pd. There is only one arm on the hard disk heads still, for example.
Which objects of Pd are actually using threads ?
It's not all of them.
Think of what is taught as the execution order of Pd, and think about how it conflicts with the idea of running everything in parallel.
Actually, among academics, the #1 reason for refusing to call Pd a dataflow language, is because they use a definition of «dataflow» that allows all messages to be threaded, whereas Pd is threading very few things.
What is the goal of Miller's new [pd~] project ? It exists because Pd itself is not already doing it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi Hans,
Hans-Christoph Steiner wrote:
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel.
Yes, there's other ways than threading. ligthttpd and HAProxy are good examples of monolithic state machine that can serve thousands of requests per second. But in some respect, they are much more simple projects than pd.
From HAProxy "design choices"
=== HAProxy implements an event-driven, single-process model which enables support for very high number of simultaneous connections at very high speeds. Multi-process or multi-threaded models can rarely cope with thousands of connections because of memory limits, system scheduler limits, and lock contention everywhere. Event-driven models do not have these problems because implementing all the tasks in user-space allows a finer resource and time management. The down side is that those programs generally don't scale well on multi-processor systems. That's the reason why they must be optimized to get the most work done from every CPU cycle. ===
The big difference is that you don't care is HAProxy if something takes 10us more.
In pd, a object like soundfiler blocks everybody else *long enough* so you can ear it, *unless * you do the hard part, that is, time slicing.
My point is that it's really really hard to write solid threaded code (that surely is a reason for pd being monoprocess in the first place). So I find it strange that pd lets it to the user. Yes, having a 4-core CPU and getting clicks in audio when you load a sample in an array is hard to swallow in 2011 ;).
And you had to do nothing to make sure that they run in parallel, don't block each other, sync up, etc.
That's the point of the discussion. A single threaded state machine is not a multi-threaded process, where time-splicing occurs at the kernel level.
Ok, so now I'm just complaining, and I can't write a threaded audio engine just yet... So, fork() it ;).
Le 2011-11-04 à 09:08:00, Charles Goyard a écrit :
Hans-Christoph Steiner wrote:
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel.
Yes, there's other ways than threading. ligthttpd and HAProxy are good examples of monolithic state machine that can serve thousands of requests per second. But in some respect, they are much more simple projects than pd.
Hans' statement is contrary to pretty much all commonly-accepted uses of the words «concurrency» and «parallel».
BTW, I once tried to use the word «parallel» to mean a bunch of computations that don't have any dependencies with each other. I paid the price for doing so and I changed my wording pretty quickly.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 8, 2011, at 9:34 AM, Mathieu Bouchard wrote:
Le 2011-11-04 à 09:08:00, Charles Goyard a écrit :
Hans-Christoph Steiner wrote:
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel.
Yes, there's other ways than threading. ligthttpd and HAProxy are good examples of monolithic state machine that can serve thousands of requests per second. But in some respect, they are much more simple projects than pd.
Hans' statement is contrary to pretty much all commonly-accepted uses of the words «concurrency» and «parallel».
BTW, I once tried to use the word «parallel» to mean a bunch of computations that don't have any dependencies with each other. I paid the price for doing so and I changed my wording pretty quickly.
You have to remember that words can have different meanings in different contexts. We are not CS professors, this is the Pd list, so this context changes which meaning are most likely to be understood.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Le 2011-11-08 à 10:40:00, Hans-Christoph Steiner a écrit :
You have to remember that words can have different meanings in different contexts. We are not CS professors, this is the Pd list, so this context changes which meaning are most likely to be understood.
If I were a CS professor or trying to use exactly the same vocabulary as them, I would have never ever claimed that PureData is dataflow, and I would have argued against using the word «dataflow» to describe PureData.
The use of the word «parallel» that I'm talking about, has a much widespread use than just CS departments.
And I still don't understand what you're trying to say about objects running in parallel or concurrently. The point is that you're not trying to make yourself understood because you're not giving us the context for understanding your meaning of the words «parallel» and «concurrency» that you still haven't stated after writing http://lists.puredata.info/pipermail/pd-list/2011-11/092330.html which looks plain wrong with the standard definitions that all developers use for this.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi,
Mathieu Bouchard wrote:
And I still don't understand what you're trying to say about objects running in parallel or concurrently.
Hans and I are talking from the user (user=the guy that creates a patch) point of view. That is, it _looks like_ objects do things in parallel when patched with parallel cords. Of course that's not true, pure-data is more of a multiplexed state-machine, just like an ethernet network.
In that respect, soundfiler is not made to run well in a switched environnement such as pd. Just like a network interface that would saturate a link, ignoring time-slots, collision-detection and such.
Does "switched state-machine" sounds good to define pd's core ?
Le 2011-11-10 à 09:54:00, Charles Goyard a écrit :
Hans and I are talking from the user (user=the guy that creates a patch) point of view. That is, it _looks like_ objects do things in parallel when patched with parallel cords.
That's not from a user's perspective, that's the perspective of someone who doesn't have a clue. A real user learns about execution order, [t] order and [unpack] order in the first few hours of learning. Those who don't actually get their job done by someone who knows. (this doesn't take ~-objects into account, who use a different execution model)
Of course that's not true, pure-data is more of a multiplexed state-machine, just like an ethernet network. [...] Does "switched state-machine" sounds good to define pd's core ?
Well... sounds like a math undergrad exercise of fitting any state transition model onto a possibly infinite-by-infinite matrix and then try to multiply it by an infinite vector of markov chain state probabilities, using limits and stuff. I vaguely remember doing this in 2nd year at UdeM. It's one of those « anything can be expressed as anything else » kind of exercise.
When trying to be practical, though, flat state machines are usually ineffectual, and nearly everybody who says just « state machine » means the flat thing. Some came up with something named hierarchical state machine, which is a much more useful model for nesting stuff, because it uses a stack. But to understand PureData, the whole GOTO concept at heart of state machines is not very useful. You still need to distinguish how many messages a [t] or a [until] has sent, but the GOTO model isn't so useful for that, especially when number of states are variable or unlimited, but also any time that a metaphor of storage can be used (e.g. [until] uses an internal int variable to count iterations when it needs to). But overall, it's better to put a lot more emphasis on stack metaphors when teaching Pd, because a lot of Pd is to send messages (function call) and to come back (return) from the processing of a message.
In that respect, soundfiler is not made to run well in a switched environnement such as pd. Just like a network interface that would saturate a link, ignoring time-slots, collision-detection and such.
The big resemblance between the two is really just the realtime aspect. Apart from that, Pd doesn't generally ever discards any data, whereas a network switch has to, and Pd does its execution mainly by depth-first searches, whereas network switches hardly ever have to do any recursion.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Charles Goyard cg@fsck.fr Cc: pd-list@iem.at Sent: Thursday, November 10, 2011 11:27 AM Subject: Re: [PD] Interruption of audio / Loading sound into array
[...]
(this doesn't take ~-objects into account, who use a different execution model)
breadth-first?
Of course that's not true, pure-data is more of a multiplexed
state-machine, just like an ethernet network. [...] Does "switched state-machine" sounds good to define pd's core ?
Well... sounds like a math undergrad exercise of fitting any state transition model onto a possibly infinite-by-infinite matrix and then try to multiply it by an infinite vector of markov chain state probabilities, using limits and stuff. I vaguely remember doing this in 2nd year at UdeM. It's one of those « anything can be expressed as anything else » kind of exercise.
When trying to be practical, though, flat state machines are usually ineffectual, and nearly everybody who says just « state machine » means the flat thing. Some came up with something named hierarchical state machine, which is a much more useful model for nesting stuff, because it uses a stack. But to understand PureData, the whole GOTO concept at heart of state machines is not very useful. You still need to distinguish how many messages a [t] or a [until] has sent, but the GOTO model isn't so useful for that, especially when number of states are variable or unlimited, but also any time that a metaphor of storage can be used (e.g. [until] uses an internal int variable to count iterations when it needs to). But overall, it's better to put a lot more emphasis on stack metaphors when teaching Pd, because a lot of Pd is to send messages (function call) and to come back (return) from the processing of a message.
In that respect, soundfiler is not made to run well in a switched environnement such as pd. Just like a network interface that would saturate a link, ignoring time-slots, collision-detection and such.
The big resemblance between the two is really just the realtime aspect. Apart from that, Pd doesn't generally ever discards any data, whereas a network switch has to, and Pd does its execution mainly by depth-first searches, whereas network switches hardly ever have to do any recursion.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-10 à 08:46:00, Jonathan Wilkes a écrit :
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca
(this doesn't take ~-objects into account, who use a different execution model)
breadth-first?
No. Breadth-first (queueing) is the execution model of t_clock components, which are central to [delay], [pipe], [metro], and other such things.
I say that breadth-first is queueing, because if you replace every connection by a generic message pipe that does the same to messages as [pipe 0] does to floats, then a tree (of objects and connections) gets traversed breadth-first, as anything down gets delayed to after the current stack of things is done with, in the t_clock queue of things to do «now».
However, the DSP uses a model in which data is flowing more regularly, such that order of execution often does not matter, as for example, if I take data from [osc~] into both an [expr~] and a [cpole~], and from both of them into a [*~], then the [*~] will get the same data regardless of whether [expr~] or [cpole~] gets executed first. The only place where this breaks, is if a given DSP order causes a 1-block delay on certain send/receive or throw/catch tasks. And also dsp loops are forbidden.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Charles Goyard cg@fsck.fr; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, November 12, 2011 3:34 PM Subject: Re: [PD] Interruption of audio / Loading sound into array
Le 2011-11-10 à 08:46:00, Jonathan Wilkes a écrit :
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca
(this doesn't take ~-objects into account, who use a different execution model)
breadth-first?
No. Breadth-first (queueing) is the execution model of t_clock components, which are central to [delay], [pipe], [metro], and other such things.
I say that breadth-first is queueing, because if you replace every connection by a generic message pipe that does the same to messages as [pipe 0] does to floats, then a tree (of objects and connections) gets traversed breadth-first, as anything down gets delayed to after the current stack of things is done with, in the t_clock queue of things to do «now».
However, the DSP uses a model in which data is flowing more regularly, such that order of execution often does not matter, as for example, if I take data from [osc~] into both an [expr~] and a [cpole~], and from both of them into a [*~], then the [*~] will get the same data regardless of whether [expr~] or [cpole~] gets executed first.
Ok. It's hard for me to differentiate that from breadth-first, probably because I have a hard time reading the linetraverser c code (or any c code really) and figuring out from it what the rules are for ordering the signal objects in the DSP graph.
-Jonathan
The only place where this breaks, is if a given DSP order causes a 1-block delay on certain send/receive or throw/catch tasks. And also dsp loops are forbidden.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-14 à 14:46:00, Jonathan Wilkes a écrit :
Ok. It's hard for me to differentiate that from breadth-first, probably because I have a hard time reading the linetraverser c code (or any c code really) and figuring out from it what the rules are for ordering the signal objects in the DSP graph.
I haven't really read that code either... well, at least not the d_ugen.c code, that contains dsp_add and such.
But just think that for the DSP, the order of some things don't matter, as long as when summing inputs in a buffer, the first one to do it does a plain assignment, and the other ones do a +=, and running the code does not happen before all the inputs have been added together.
So, in the DSP, things can't happen in a plain breadth-first manner, and they can't happen in a plain depth-first manner either, but they can happen if you modify those manners to prevent running the code until all the inputs are ready. In that model, it doesn't matter much whether you are running a modified depth-first or a modified breadth-first, as long as it's modified to run each perform() function at most once per block. And there are many other ways to traverse the patch in a way that would be correct, and would be neither like depth-first, nor like breadth-first.
The only place where this breaks, is if a given DSP order causes a 1-block delay on certain send/receive or throw/catch tasks. And also dsp loops are forbidden.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi,
Mathieu Bouchard wrote:
Le 2011-11-10 à 09:54:00, Charles Goyard a écrit :
Hans and I are talking from the user (user=the guy that creates a patch) point of view. That is, it _looks like_ objects do things in parallel when patched with parallel cords.
That's not from a user's perspective, that's the perspective of someone who doesn't have a clue.
I'll try to make myself crearer. Behavior like blocking on file load in a stock object is unexpected in a real-time environment.
In that respect, soundfiler is not made to run well in a switched environnement such as pd. Just like a network interface that would saturate a link, ignoring time-slots, collision-detection and such.
The big resemblance between the two is really just the realtime aspect.
Ethernet networks are fast but not realtime. They drop and ask for retransmission if necessary , whereas a realtime system ought to just drop data and go on to keep in time.
Le 2011-11-10 à 20:09:00, Charles Goyard a écrit :
Mathieu Bouchard wrote:
Le 2011-11-10 à 09:54:00, Charles Goyard a écrit :
In that respect, soundfiler is not made to run well in a switched environnement such as pd. Just like a network interface that would saturate a link, ignoring time-slots, collision-detection and such.
The big resemblance between the two is really just the realtime aspect.
Ethernet networks are fast but not realtime. They drop and ask for retransmission if necessary , whereas a realtime system ought to just drop data and go on to keep in time.
They might not have what is called realtime constraints, but they still get judged by real time aspects such as how fast each transmission is going through them, etc.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
because of the things explained by Mathieu and HC, it will never be
perfect. but there are some small solutions that can try to avoid the
problem:
- don't have any graphical display: put your array in a [table] instead of
an array, or in a subpatch where it's not showing
- load all samples before you start doing audio, if possible (there's lots
of memory available these days)
Or any smarter techniques involving upsampling etc, as said by others.
João
Hi,
This might just be a graphics related problem. Just disable thegraphical representation of the arrays (I'm not in front of Pd right now
but If I remeber well, it's just a matter of clicking on the arrays and
unchecking the "graph on parent" box). I had the very same problem under
Win XP, it solved everything.Hope this helps.
D.S
http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/
From: ingo@miamiwave.com To: sebastian.hanusa@gmx.de; pd-list@iem.at Date: Mon, 31 Oct 2011 19:24:20 +0100 Subject: Re: [PD] Interruption of audio / Loading sound into array
[soundfiler] will always interrupt the audio stream.
What I have done before was to stream the soundfile into a table with [readsf~]. You can upsample the subpatch with [block~] or [switch~] so
it reads faster than realtime.Ingo
-----UrsprÃŒngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im
Auftrag von
Sebastian Hanusa Gesendet: Montag, 31. Oktober 2011 18:37 An: pd-list@iem.at Betreff: [PD] Interruption of audio / Loading sound into array
Dear List!
I have a problem, where hope the solution is so easy as it is complicated for me to find a solution:
When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream.
I tryed to switch off the patch within the array for the moment of loading - but I get the same result.
Is there a way to avoid this dropout?
I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8
Thanks a lot for any help and with best regards,
Sebastian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read' (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html). What has become of this? Is there any code from this project?
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once. Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded. It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick. But, like Charles pointed out, it is not trivial to find an optimum. I agree Pd should better do this in C.
Katja
Hi all,
have you had a look at this:
http://grh.mur.at/software/sndfiler.html
It used to work for me, although i haven't tried for a long time (that
is, with current pd versions)
gr~~~
Am 04.11.2011 um 11:26 schrieb katja:
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read' (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html). What has become of this? Is there any code from this project?
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once. Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded. It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick. But, like Charles pointed out, it is not trivial to find an optimum. I agree Pd should better do this in C.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, Nov 4, 2011 at 11:41 AM, Thomas Grill gr@grrrr.org wrote:
Hi all, have you had a look at this: http://grh.mur.at/software/sndfiler.html It used to work for me, although i haven't tried for a long time (that is, with current pd versions) gr~~~
Hi Thomas,
Thanks for pointing to this. Seems like a very systematic approach. All the code is in pure-data.svn, but grh and tb libs are not included in 0.42 or 0.43 binary builds. Apparently these libs are no longer maintainded, and don't fit in the actual build system. At least the code is there, and it could just be a matter of reviving (parts of) it, who knows.
Katja
On Fri, 2011-11-04 at 11:26 +0100, katja wrote:
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read' (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html). What has become of this? Is there any code from this project?
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once. Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded. It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick.
The problem with the '[readsf~]-in-an-upsampled-patch' approach is that you cannot know how fast you can do it without interrupting audio. Also you cannot really fine-tune it since you can only set it to a speed to any power of two. Ideally, a threaded [soundfiler] would load the file as fas as possible in the background without interfering with Pd's main process and then it would output a bang when done.
Roman
Le 2011-11-04 à 11:50:00, Roman Haefeli a écrit :
The problem with the '[readsf~]-in-an-upsampled-patch' approach is that you cannot know how fast you can do it without interrupting audio. Also you cannot really fine-tune it since you can only set it to a speed to any power of two. Ideally, a threaded [soundfiler] would load the file as fas as possible in the background without interfering with Pd's main process and then it would output a bang when done.
Even if you do tune one [readsf~] to load at an appropriate speed, you need global control to figure out how many [readsf~] can run at once and how much upsampling you have to do on each. Then you really need to make this an abstraction (or a set thereof) because this coordination is getting too complex for copy-paste.
Blechmann-and/or-Grill's solution was to make a queue like this :
static struct t_sfqueue { t_sfprocess *begin; t_sfprocess *end; pthread_mutex_t mutex; pthread_cond_t cond; } *soundfiler_queue;
Where each t_sfprocess saves soundfiler messages for later, remembering the content and destination... and also the next-pointer for making a linked-list.
So, this means that there is only one soundfiler running at a time, which might be faster on the hard disk or not. Depends on which hard-disks they are on and whether they're cached and stuff. It's hard to get smart about it, but running only one soundfiler thread isn't a bad idea.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi,
This seems to have been debated several times. It's one of those recurring subjects. If I had only one wish for Pd it would be to have a non blocking/low priority [soundfiler] alternative.
I have the same trouble as mentioned. I have no graph for the tables, it's not a GUI issue. I thought the problem would go away with a faster disk, I switched from a rather fast laptop HDD to an SSD. No luck, not even the slightest improvement. The problem does seem to go away with a speedier CPU even-though the processor is not under a real strain from the rest of the patch. The bottle neck here is CPU crunching speed. This would mean for me either changing computer or changing my sound card for just little drop outs or switch to Live and M4L. :( Loading more stuff at the beginning is just not an option, I have already a lot loaded and I don't want the restriction of only playing with predetermined stuff.
I had to increase Pd's latency to 300ms to get rid of this on a Core2duo 1.6GHz processor and split the different files into short mono files which restrict the number of elements in each sound bank I'm loading. As this patch is a random sample player running in auto it's not so important if there is some latency, I'm more concerned with the length restriction. More bugging is the MIDI latency that follows the sound latency. It really makes things awkward because you have to either be very slow and patient when moving the controls (it can break the MIDI connexion with looping even if I patched something that tries to prevent that) or split the MIDI subpatch into a separate patch and have net-send/receive on both sides.
Most people loading stuff for sample players already handle the restricted access to the tables being loaded. As long as something happens at the end of the loading (output of the file length) it's ok, we know when loading starts and finishes.
Sorry if I sound raunchy. It's one hassle I have with Pd and my coding knowledge being what it is I can't do more than rant. :)
Cheers Pierre-Olivier
On 04/11/2011 11:26, katja wrote:
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read' (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html). What has become of this? Is there any code from this project?
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once. Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded. It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick. But, like Charles pointed out, it is not trivial to find an optimum. I agree Pd should better do this in C.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-04 à 11:26:00, katja a écrit :
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read'
But (multi)threaded [soundfiler] had already been implemented in 2005 (or 2004 ?) by Tim Blechmann.
This and other things didn't get accepted by Miller's branch. In the end, Blechmann decided to become a SuperCollider developer and apparently has stopped using pd.
His threaded [soundfiler] is not in 0.43 either.
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once.
No, they could read it with a single thread, but it would be bad for latency, because the process could be blocked while waiting for the harddisk, and on top of that, the non-blocking mode (of read/write) usually doesn't work for ordinary files (when I tried, it only worked on pipes and sockets and perhaps some other things, but not ordinary files).
Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded.
Look for a branch named devel_0_39.
I don't find anything named like « threaded soundfiler » in the sourceforge tracker, so, it's possible that it hadn't submitted. But that might have been already the time at which we started to doubt that things submitted in the tracker forms were likely to be accepted.
It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick.
If [readsf~]-in-an-upsampled-patch is really a good trick, I dare Miller to publish it as an abstraction with pd, which would be called soundfiler2.pd or similar.
But no abstractions at all are provided with pd, except demos in the tutorials. Which is weird for software in which most users rely heavily on abstractions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: katja katjavetter@gmail.com Cc: pd-list@iem.at Sent: Friday, November 4, 2011 12:21 PM Subject: Re: [PD] Interruption of audio / Loading sound into array
Le 2011-11-04 à 11:26:00, katja a écrit :
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read'
But (multi)threaded [soundfiler] had already been implemented in 2005 (or 2004 ?) by Tim Blechmann.
This and other things didn't get accepted by Miller's branch. In the end, Blechmann decided to become a SuperCollider developer and apparently has stopped using pd.
His threaded [soundfiler] is not in 0.43 either.
Well if it works it should go into Pd-extended 0.43. But if it goes into Pd-extended 0.43, who will maintain it if there are bugs?
-Jonathan
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once.
No, they could read it with a single thread, but it would be bad for latency, because the process could be blocked while waiting for the harddisk, and on top of that, the non-blocking mode (of read/write) usually doesn't work for ordinary files (when I tried, it only worked on pipes and sockets and perhaps some other things, but not ordinary files).
Looking at the code in d_soundfile.c, I can understand why the whole of Pd
should not be multithreaded.
Look for a branch named devel_0_39.
I don't find anything named like « threaded soundfiler » in the sourceforge tracker, so, it's possible that it hadn't submitted. But that might have been already the time at which we started to doubt that things submitted in the tracker forms were likely to be accepted.
It is a lot of overhead. But [soundfiler~] read is another exceptional case
indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick.
If [readsf~]-in-an-upsampled-patch is really a good trick, I dare Miller to publish it as an abstraction with pd, which would be called soundfiler2.pd or similar.
But no abstractions at all are provided with pd, except demos in the tutorials. Which is weird for software in which most users rely heavily on abstractions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
Well if it works it should go into Pd-extended 0.43. But if it goes into Pd-extended 0.43, who will maintain it if there are bugs?
What power would be granted to such a maintainer to ensure that the bugfixes do get in pd-extended binaries ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, November 4, 2011 2:08 PM Subject: Re: [PD] Interruption of audio / Loading sound into array
Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
Well if it works it should go into Pd-extended 0.43. But if it goes into
Pd-extended 0.43, who will maintain it if there are bugs?
What power would be granted to such a maintainer to ensure that the bugfixes do get in pd-extended binaries ?
Well if it's a libdir external it would be easy, right?
If it's a replacement for [soundfiler] I'm not sure.
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 4, 2011, at 2:08 PM, Mathieu Bouchard wrote:
Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
Well if it works it should go into Pd-extended 0.43. But if it goes into Pd-extended 0.43, who will maintain it if there are bugs?
What power would be granted to such a maintainer to ensure that the bugfixes do get in pd-extended binaries ?
Everyone has the power, they just need to do the work.
.hc
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, November 4, 2011 7:01 PM Subject: Re: [PD] Interruption of audio / Loading sound into array
On Nov 4, 2011, at 2:08 PM, Mathieu Bouchard wrote:
Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
Well if it works it should go into Pd-extended 0.43. But if it goes
into Pd-extended 0.43, who will maintain it if there are bugs?
What power would be granted to such a maintainer to ensure that the
bugfixes do get in pd-extended binaries ?
Everyone has the power, they just need to do the work.
Right.
This feature is a reasonable request with considerable demand (as it keeps popping up on the list). Since some form of it seems to have already been coded, there needs to be a way to incorporate it into Pd extended without requiring Hans to do all the work, on the one hand, and without requiring an additional maintainer to vouch to be its guardian for all eternity.
Would it be possible to have one or more devs to a) steward it into an alpha state that can be included in the nightly builds and b) keep an eye on it through the next version of Pd in case of bugs? That way there are specific goals, so that any interested Pders could fund a dev (or more than one dev) to achieve these, without requiring those devs to "adopt" the object class as their permanent responsibility, and without piling more work on Hans in the leadup to and maintenance of 0.43.
-Jonathan
.hc
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
-
Charles Goyard -
Claude Heiland-Allen -
David Schaffer -
Hans-Christoph Steiner -
Ingo -
Ingo Scherzinger
-
Jonathan Wilkes -
João Pais -
katja -
Mathieu Bouchard -
Pierre-Olivier Boulant -
Roman Haefeli -
Sebastian Hanusa -
Thomas Grill