Thread: [Audacity-devel] multithreading
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
Menu
▾
▴
audacity-devel
|
From: Alexandre P. <ale...@gm...> - 2009-01-29 19:54:49
|
Hi, Recently, while moving my stuff to a new Core2 Quad PC, I stumbled upon a 8:45 h long recording of a conference dating back to 2003 that I haven't processed yet for some reason (lack of free space most likely). So I gave it a go and started with normalization. At the time I was having a GNOME System Monitor dialog floating around and I noticed that only one core was busy. I never really thought about Audacity in terms of threaded design before. So here comes the question. Does it makes sense to make Audacity SMP aware? If yes, do we have plans for that? Or is I/O what sets limit to processing speed, not CPU? Alexandre |
|
From: Ruan B. <rua...@gm...> - 2009-01-30 03:24:31
|
2009/1/30 Alexandre Prokoudine <ale...@gm...>: > Hi, > > Recently, while moving my stuff to a new Core2 Quad PC, I stumbled > upon a 8:45 h long recording of a conference dating back to 2003 that > I haven't processed yet for some reason (lack of free space most > likely). So I gave it a go and started with normalization. At the time > I was having a GNOME System Monitor dialog floating around and I > noticed that only one core was busy. I never really thought about > Audacity in terms of threaded design before. > > So here comes the question. Does it makes sense to make Audacity SMP > aware? If yes, do we have plans for that? Or is I/O what sets limit to > processing speed, not CPU? > > Alexandre > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > Hi, I believe that the multithreading is an important feature of such a software, because software doing something with audio or video may be the most common software that benefits most from SMP. It seems that the develop team hasn't put this staff their priority. -- James Ruan |
|
From: Leland <le...@au...> - 2009-01-30 03:39:14
|
Alexandre Prokoudine wrote: > Hi, > > Recently, while moving my stuff to a new Core2 Quad PC, I stumbled > upon a 8:45 h long recording of a conference dating back to 2003 that > I haven't processed yet for some reason (lack of free space most > likely). So I gave it a go and started with normalization. At the time > I was having a GNOME System Monitor dialog floating around and I > noticed that only one core was busy. I never really thought about > Audacity in terms of threaded design before. > > So here comes the question. Does it makes sense to make Audacity SMP > aware? If yes, do we have plans for that? Or is I/O what sets limit to > processing speed, not CPU? > I'd have to go back in the archives, but Dominic and Lynne Anderson had discussed this a couple of years ago and I think Dominic thought it wouldn't be a good idea...but don't quote me as I may be remembering it incorrectly. And, he's right for 99% of the cases. For instance how many times have you needed to load two files at once? Or apply two effects to the same bit of music at the same time (okay...don't count that one. ;-)) However, if I'm taking your meaning correctly, then how about using something like OpenCL to break down some of the larger, time (and CPU) consuming tasks like applying effects. And since OpenCL is plain old C, we wouldn't have learn a whole new language. Check the Wikipedia page for an FFT example: http://en.wikipedia.org/wiki/OpenCL#Example Leland |
|
From: Ruan B. <rua...@gm...> - 2009-01-30 05:20:49
|
2009/1/30 Leland <le...@au...>: > Alexandre Prokoudine wrote: >> Hi, >> >> Recently, while moving my stuff to a new Core2 Quad PC, I stumbled >> upon a 8:45 h long recording of a conference dating back to 2003 that >> I haven't processed yet for some reason (lack of free space most >> likely). So I gave it a go and started with normalization. At the time >> I was having a GNOME System Monitor dialog floating around and I >> noticed that only one core was busy. I never really thought about >> Audacity in terms of threaded design before. >> >> So here comes the question. Does it makes sense to make Audacity SMP >> aware? If yes, do we have plans for that? Or is I/O what sets limit to >> processing speed, not CPU? >> > > I'd have to go back in the archives, but Dominic and Lynne Anderson had > discussed this a couple of years ago and I think Dominic thought it > wouldn't be a good idea...but don't quote me as I may be remembering it > incorrectly. > > And, he's right for 99% of the cases. For instance how many times have > you needed to load two files at once? Or apply two effects to the same > bit of music at the same time (okay...don't count that one. ;-)) > > However, if I'm taking your meaning correctly, then how about using > something like OpenCL to break down some of the larger, time (and CPU) > consuming tasks like applying effects. And since OpenCL is plain old C, > we wouldn't have learn a whole new language. Check the Wikipedia page > for an FFT example: > > http://en.wikipedia.org/wiki/OpenCL#Example > > > Leland > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > >And, he's right for 99% of the cases. For instance how many times have >you needed to load two files at once? Or apply two effects to the same >bit of music at the same time (okay...don't count that one. ;-)) There are actually cases. For many time I want a file be exporting to MP3 while another file be loading and then be normalizing. I find recent versions of Audacity have chains of operation that done on files, why not use multithreading to make it parallel among files. (I'm not a native English speaker. Forgive me if I said something strange.) I mean that, apply a chain on one file in one thread, and apply the chain on next file in another thread, and make the threading number custom. Though programming in multithread is harder than normal one, since the CPU enters a era of SMP even many-core, this feature is worthwhile. And as to the OpenCL or CUDA, they are still too new and far too limited for putting into generic use. -- James Ruan |
|
From: LRN <lr...@gm...> - 2009-01-30 05:46:15
|
Ruan Beihong wrote: > 2009/1/30 Leland <le...@au...>: > >> Alexandre Prokoudine wrote: >> >>> Hi, >>> >>> Recently, while moving my stuff to a new Core2 Quad PC, I stumbled >>> upon a 8:45 h long recording of a conference dating back to 2003 that >>> I haven't processed yet for some reason (lack of free space most >>> likely). So I gave it a go and started with normalization. At the time >>> I was having a GNOME System Monitor dialog floating around and I >>> noticed that only one core was busy. I never really thought about >>> Audacity in terms of threaded design before. >>> >>> So here comes the question. Does it makes sense to make Audacity SMP >>> aware? If yes, do we have plans for that? Or is I/O what sets limit to >>> processing speed, not CPU? >>> >>> >> I'd have to go back in the archives, but Dominic and Lynne Anderson had >> discussed this a couple of years ago and I think Dominic thought it >> wouldn't be a good idea...but don't quote me as I may be remembering it >> incorrectly. >> >> And, he's right for 99% of the cases. For instance how many times have >> you needed to load two files at once? Or apply two effects to the same >> bit of music at the same time (okay...don't count that one. ;-)) >> >> However, if I'm taking your meaning correctly, then how about using >> something like OpenCL to break down some of the larger, time (and CPU) >> consuming tasks like applying effects. And since OpenCL is plain old C, >> we wouldn't have learn a whole new language. Check the Wikipedia page >> for an FFT example: >> >> http://en.wikipedia.org/wiki/OpenCL#Example >> >> And, he's right for 99% of the cases. For instance how many times have >> you needed to load two files at once? Or apply two effects to the same >> bit of music at the same time (okay...don't count that one. ;-)) >> > > There are actually cases. For many time I want a file be exporting to > MP3 while another file be loading and then be normalizing. I find > recent versions of Audacity have chains of operation that done on > files, why not use multithreading to make it parallel among files. > (I'm not a native English speaker. Forgive me if I said something > strange.) I mean that, apply a chain on one file in one thread, and > apply the chain on next file in another thread, and make the threading > number custom. > Though programming in multithread is harder than normal one, since the > CPU enters a era of SMP even many-core, this feature is worthwhile. > And as to the OpenCL or CUDA, they are still too new and far too > limited for putting into generic use. [1]"Do two things simultaneously" scheme requires Audacity redesign - it has to be more threaded. OpenCL wouldn't help here. Recent OnDemandLoading feature is an example of threaded design. [2] "Do one thing in two threads, which makes it go ~2 times faster" requires special implementation. That's where things such as OpenCL would help. But it's not cost-effective to rewrite everything in SMP-style. Only costly operations should be made parallel, everything else would benefit more from threaded design (see [1]). |
|
From: Richard A. <ri...@au...> - 2009-02-02 21:03:23
|
On Fri, 2009-01-30 at 08:46 +0300, LRN wrote: > > Though programming in multithread is harder than normal one, since the > > CPU enters a era of SMP even many-core, this feature is worthwhile. > > And as to the OpenCL or CUDA, they are still too new and far too > > limited for putting into generic use. > [1]"Do two things simultaneously" scheme requires Audacity redesign - it > has to be more threaded. OpenCL wouldn't help here. Recent > OnDemandLoading feature is an example of threaded design. > [2] "Do one thing in two threads, which makes it go ~2 times faster" > requires special implementation. That's where things such as OpenCL > would help. But it's not cost-effective to rewrite everything in > SMP-style. Only costly operations should be made parallel, everything > else would benefit more from threaded design (see [1]). Well put. Audacity has both CPU-bound and IO-bound effects, and quite a few where the balance is not far off even, depending on how good your CPU and HDD are. Redesign to do multiple things at once is _very_ hard work to do well and completely (think how much Micheal has had to do to stop his import threads treading on each others toes). Multi-threading single sections on a case-by-case basis is obviously less universal, but can be a shorter way to obtain a seriously quicker run of that effect. Unless the code inside the effect is seriously ugly to start with, it should be less work to do. Richard |
|
From: Gordon W. <gor...@ch...> - 2009-02-02 00:16:45
|
I didn't see anyone mention the obvious multithreading. Left channel in one task and right channel in another. Virtually all effects will benefit from this. I believe that left and right channel data are kept in separate buffers, so there wouldn't be any cache contention doing this. If you're working with more than 2 tracks, then more cores could come into play with it. Gordon Weast LRN wrote: > Ruan Beihong wrote: > >> 2009/1/30 Leland <le...@au...>: >> >> >>> Alexandre Prokoudine wrote: >>> >>> >>>> Hi, >>>> >>>> Recently, while moving my stuff to a new Core2 Quad PC, I stumbled >>>> upon a 8:45 h long recording of a conference dating back to 2003 that >>>> I haven't processed yet for some reason (lack of free space most >>>> likely). So I gave it a go and started with normalization. At the time >>>> I was having a GNOME System Monitor dialog floating around and I >>>> noticed that only one core was busy. I never really thought about >>>> Audacity in terms of threaded design before. >>>> >>>> So here comes the question. Does it makes sense to make Audacity SMP >>>> aware? If yes, do we have plans for that? Or is I/O what sets limit to >>>> processing speed, not CPU? >>>> >>>> >>>> >>> I'd have to go back in the archives, but Dominic and Lynne Anderson had >>> discussed this a couple of years ago and I think Dominic thought it >>> wouldn't be a good idea...but don't quote me as I may be remembering it >>> incorrectly. >>> >>> And, he's right for 99% of the cases. For instance how many times have >>> you needed to load two files at once? Or apply two effects to the same >>> bit of music at the same time (okay...don't count that one. ;-)) >>> >>> However, if I'm taking your meaning correctly, then how about using >>> something like OpenCL to break down some of the larger, time (and CPU) >>> consuming tasks like applying effects. And since OpenCL is plain old C, >>> we wouldn't have learn a whole new language. Check the Wikipedia page >>> for an FFT example: >>> >>> http://en.wikipedia.org/wiki/OpenCL#Example >>> >>> And, he's right for 99% of the cases. For instance how many times have >>> you needed to load two files at once? Or apply two effects to the same >>> bit of music at the same time (okay...don't count that one. ;-)) >>> >>> >> There are actually cases. For many time I want a file be exporting to >> MP3 while another file be loading and then be normalizing. I find >> recent versions of Audacity have chains of operation that done on >> files, why not use multithreading to make it parallel among files. >> (I'm not a native English speaker. Forgive me if I said something >> strange.) I mean that, apply a chain on one file in one thread, and >> apply the chain on next file in another thread, and make the threading >> number custom. >> Though programming in multithread is harder than normal one, since the >> CPU enters a era of SMP even many-core, this feature is worthwhile. >> And as to the OpenCL or CUDA, they are still too new and far too >> limited for putting into generic use. >> > [1]"Do two things simultaneously" scheme requires Audacity redesign - it > has to be more threaded. OpenCL wouldn't help here. Recent > OnDemandLoading feature is an example of threaded design. > [2] "Do one thing in two threads, which makes it go ~2 times faster" > requires special implementation. That's where things such as OpenCL > would help. But it's not cost-effective to rewrite everything in > SMP-style. Only costly operations should be made parallel, everything > else would benefit more from threaded design (see [1]). > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > |
|
From: Ruan B. <rua...@gm...> - 2009-02-02 05:35:28
|
Quite right, you've suggested a obvious but very useful one. 2009/2/2 Gordon Weast <gor...@ch...>: > I didn't see anyone mention the obvious multithreading. Left channel in one > task and right channel in another. Virtually all effects will benefit > from this. > > I believe that left and right channel data are kept in separate buffers, > so there wouldn't be any cache contention doing this. > > If you're working with more than 2 tracks, then more cores could > come into play with it. > > Gordon Weast > > LRN wrote: >> Ruan Beihong wrote: >> >>> 2009/1/30 Leland <le...@au...>: >>> >>> >>>> Alexandre Prokoudine wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> Recently, while moving my stuff to a new Core2 Quad PC, I stumbled >>>>> upon a 8:45 h long recording of a conference dating back to 2003 that >>>>> I haven't processed yet for some reason (lack of free space most >>>>> likely). So I gave it a go and started with normalization. At the time >>>>> I was having a GNOME System Monitor dialog floating around and I >>>>> noticed that only one core was busy. I never really thought about >>>>> Audacity in terms of threaded design before. >>>>> >>>>> So here comes the question. Does it makes sense to make Audacity SMP >>>>> aware? If yes, do we have plans for that? Or is I/O what sets limit to >>>>> processing speed, not CPU? >>>>> >>>>> >>>>> >>>> I'd have to go back in the archives, but Dominic and Lynne Anderson had >>>> discussed this a couple of years ago and I think Dominic thought it >>>> wouldn't be a good idea...but don't quote me as I may be remembering it >>>> incorrectly. >>>> >>>> And, he's right for 99% of the cases. For instance how many times have >>>> you needed to load two files at once? Or apply two effects to the same >>>> bit of music at the same time (okay...don't count that one. ;-)) >>>> >>>> However, if I'm taking your meaning correctly, then how about using >>>> something like OpenCL to break down some of the larger, time (and CPU) >>>> consuming tasks like applying effects. And since OpenCL is plain old C, >>>> we wouldn't have learn a whole new language. Check the Wikipedia page >>>> for an FFT example: >>>> >>>> http://en.wikipedia.org/wiki/OpenCL#Example >>>> >>>> And, he's right for 99% of the cases. For instance how many times have >>>> you needed to load two files at once? Or apply two effects to the same >>>> bit of music at the same time (okay...don't count that one. ;-)) >>>> >>>> >>> There are actually cases. For many time I want a file be exporting to >>> MP3 while another file be loading and then be normalizing. I find >>> recent versions of Audacity have chains of operation that done on >>> files, why not use multithreading to make it parallel among files. >>> (I'm not a native English speaker. Forgive me if I said something >>> strange.) I mean that, apply a chain on one file in one thread, and >>> apply the chain on next file in another thread, and make the threading >>> number custom. >>> Though programming in multithread is harder than normal one, since the >>> CPU enters a era of SMP even many-core, this feature is worthwhile. >>> And as to the OpenCL or CUDA, they are still too new and far too >>> limited for putting into generic use. >>> >> [1]"Do two things simultaneously" scheme requires Audacity redesign - it >> has to be more threaded. OpenCL wouldn't help here. Recent >> OnDemandLoading feature is an example of threaded design. >> [2] "Do one thing in two threads, which makes it go ~2 times faster" >> requires special implementation. That's where things such as OpenCL >> would help. But it's not cost-effective to rewrite everything in >> SMP-style. Only costly operations should be made parallel, everything >> else would benefit more from threaded design (see [1]). >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > -- James Ruan |
|
From: Richard A. <ri...@au...> - 2009-02-02 21:17:15
|
On Sun, 2009-02-01 at 19:16 -0500, Gordon Weast wrote: > I didn't see anyone mention the obvious multithreading. Left channel in one > task and right channel in another. Virtually all effects will benefit > from this. Assuming that they apply independently to each channel (the soundtouch ones don't, they actually work in stereo on stereo tracks) and that you work with >=stereo audio rather than mono. Even with those provisos, it's a worthwhile idea to persue. > I believe that left and right channel data are kept in separate buffers, > so there wouldn't be any cache contention doing this. For effects obeying the above rules, then there isn't an issue as far as the main audio data is concerned. The problems come with all the peripheral stuff that is shared (effect dialogue, progress dialogue, undo history ...). None of these are insurmountable, but neither are they trivial. It needs a reasonable amount of design work to make it happen successfully. I think the correct way to tackle this is to look at the EffectSimpleMono class, which is the parent of most of the effects that meet my conditions above, and I think deals with the task of handing out multiple audio tracks for processing (I think this is currently done in series). At low level effects should all now work by processing from the current clip into a new clip, then swapping the clips when the effect is complete (which is done so that cancelled effects don't leave processed audio around). So working with those temporary clips in multiple threads should make some of the pitfalls I mentioned easier. EffectSimpleMono could then be altered so that if a flag was set in the derived class, instead of the tasks running in series, they run in parallel in a finite number of threads. There needs to be some sort of flag from the individual effects, because running I/O bound ones in multiple threads will make life worse, not better (I/O is less continuous, but CPUs weren't busy anyway). The reverse and invert effects would be examples where threading isn't of much use. So I think it would make a great project for someone with time to devote to learning about threading issues (or someone who already knows about threads), making use of the worker thread code that Micheal has already written for on-demand import of PCM audio. But I don't think anyone on the current team has a huge appetite for working on it any time soon. Richard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X