Hi.

First Post. I'm using csound(linux) for a while and i'm starting to
encounter stuttering when running it with moderately complex
orchestras in realtime. I did most of the usual orchestra
optimizations, but the calculations seem to be still a little bit too
heavy to take on in realtime. Now I'd like to reduce the samplerate to
maybe 32000 or maybe 22050 at least for realtime previewing, but my
laptop soundchip does not support sample rates lower than 44.1khz. Is
there a way in csound to render for a lower samplerate but play the
result resampled for a higher rate (in realtime)? Or will i have to
check for an external tool (via alsa or jack) that mimicks a soundcard
supporting lower samplerates?

Thanks in advance,
.cc


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hm, my first thought is that it might be more trouble than it's worth,
unless you're trying to squeeze the last drops of performance out of a
slow computer (i.e.netbook or cellphone).

Maybe you've already tried it, but using a lower kr will in many cases
improve performance significantly.
Also, if you have stuttering in realtime, it might be related to
poorly adjusted buffer sizes.
As a quick check, can you render your csd to file (e.g. -otest.wav)
and see if it's really the CPU time that is the bottleneck?
For example, if you have a score with a duration of one minute, and it
renders in 30 seconds when writing to file, then your number crunching
performance is fine, but the stuttering probebly stems from poorly
adjusted buffers.

Sorry if this is too obvious, and I know, I'm not really answering
your question ... :-)
Oeyvind

2011/1/23 Christopher Charles :
> Hi.
>
> First Post. I'm using csound(linux) for a while and i'm starting to
> encounter stuttering when running it with moderately complex
> orchestras in realtime. I did most of the usual orchestra
> optimizations, but the calculations seem to be still a little bit too
> heavy to take on in realtime. Now I'd like to reduce the samplerate to
> maybe 32000 or maybe 22050 at least for realtime previewing, but my
> laptop soundchip does not support sample rates lower than 44.1khz. Is
> there a way in csound to render for a lower samplerate but play the
> result resampled for a higher rate (in realtime)? Or will i have to
> check for an external tool (via alsa or jack) that mimicks a soundcard
> supporting lower samplerates?
>
> Thanks in advance,
> .cc
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

in addition to oeyvind's suggestions: i have a netbook with ubuntu, and
it runs quite fine. have you had a look at
http://www.csounds.com/manual/html/UsingOptimizing.html ?
(some tips are also in
http://booki.flossmanuals.net/csound/_v/1.0/d-live-audio/)
at any case, try to tweak ksmps, -b and -B, but do not reduce the sample
rate.
you can post your .csd here to find out if there is something wrong with
it, if you have no success.

	joachim

Am 23.01.2011 22:45, schrieb Oeyvind Brandtsegg:
> Hm, my first thought is that it might be more trouble than it's worth,
> unless you're trying to squeeze the last drops of performance out of a
> slow computer (i.e.netbook or cellphone).
> 
> Maybe you've already tried it, but using a lower kr will in many cases
> improve performance significantly.
> Also, if you have stuttering in realtime, it might be related to
> poorly adjusted buffer sizes.
> As a quick check, can you render your csd to file (e.g. -otest.wav)
> and see if it's really the CPU time that is the bottleneck?
> For example, if you have a score with a duration of one minute, and it
> renders in 30 seconds when writing to file, then your number crunching
> performance is fine, but the stuttering probebly stems from poorly
> adjusted buffers.
> 
> Sorry if this is too obvious, and I know, I'm not really answering
> your question ... :-)
> Oeyvind
> 
> 2011/1/23 Christopher Charles :
>> Hi.
>>
>> First Post. I'm using csound(linux) for a while and i'm starting to
>> encounter stuttering when running it with moderately complex
>> orchestras in realtime. I did most of the usual orchestra
>> optimizations, but the calculations seem to be still a little bit too
>> heavy to take on in realtime. Now I'd like to reduce the samplerate to
>> maybe 32000 or maybe 22050 at least for realtime previewing, but my
>> laptop soundchip does not support sample rates lower than 44.1khz. Is
>> there a way in csound to render for a lower samplerate but play the
>> result resampled for a higher rate (in realtime)? Or will i have to
>> check for an external tool (via alsa or jack) that mimicks a soundcard
>> supporting lower samplerates?
>>
>> Thanks in advance,
>> .cc
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Alsa plughw might be the answer.  Get alsa to do the resampling, and a 2x
resample should be OK

Sorry not to be more help -- alsa is a bit of a mystery



> Hm, my first thought is that it might be more trouble than it's worth,
> unless you're trying to squeeze the last drops of performance out of a
> slow computer (i.e.netbook or cellphone).
>
> Maybe you've already tried it, but using a lower kr will in many cases
> improve performance significantly.
> Also, if you have stuttering in realtime, it might be related to
> poorly adjusted buffer sizes.
> As a quick check, can you render your csd to file (e.g. -otest.wav)
> and see if it's really the CPU time that is the bottleneck?
> For example, if you have a score with a duration of one minute, and it
> renders in 30 seconds when writing to file, then your number crunching
> performance is fine, but the stuttering probebly stems from poorly
> adjusted buffers.
>
> Sorry if this is too obvious, and I know, I'm not really answering
> your question ... :-)
> Oeyvind
>
> 2011/1/23 Christopher Charles :
>> Hi.
>>
>> First Post. I'm using csound(linux) for a while and i'm starting to
>> encounter stuttering when running it with moderately complex
>> orchestras in realtime. I did most of the usual orchestra
>> optimizations, but the calculations seem to be still a little bit too
>> heavy to take on in realtime. Now I'd like to reduce the samplerate to
>> maybe 32000 or maybe 22050 at least for realtime previewing, but my
>> laptop soundchip does not support sample rates lower than 44.1khz. Is
>> there a way in csound to render for a lower samplerate but play the
>> result resampled for a higher rate (in realtime)? Or will i have to
>> check for an external tool (via alsa or jack) that mimicks a soundcard
>> supporting lower samplerates?
>>
>> Thanks in advance,
>> .cc
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>




Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hello, thanks for your suggestions,

i've already reduced kr some while ago, which helped a little bit, but
not enough. Then i tried the filewriting and got the following result:
The score plays about 240s in realtime, and takes 138s to render (on
linux). So it really seems to be ill-setup buffers. What bugs me more
is that while rendering on linux took 138s, on windows it was only 46s
(windows realtime playback is flawless, always taking less than 50%
cpu time). So in addition to the buffers, the linux version is either
compiled without the right optimizations or i'm suffering cpu-scaling
issues. Will have to investigate on that as well as the buffer setup.
jpff's hint on hwplug also seems worth a try.

Thanks very much,
.cc

2011/1/23 Oeyvind Brandtsegg :
> Hm, my first thought is that it might be more trouble than it's worth,
> unless you're trying to squeeze the last drops of performance out of a
> slow computer (i.e.netbook or cellphone).
>
> Maybe you've already tried it, but using a lower kr will in many cases
> improve performance significantly.
> Also, if you have stuttering in realtime, it might be related to
> poorly adjusted buffer sizes.
> As a quick check, can you render your csd to file (e.g. -otest.wav)
> and see if it's really the CPU time that is the bottleneck?
> For example, if you have a score with a duration of one minute, and it
> renders in 30 seconds when writing to file, then your number crunching
> performance is fine, but the stuttering probebly stems from poorly
> adjusted buffers.
>
> Sorry if this is too obvious, and I know, I'm not really answering
> your question ... :-)
> Oeyvind


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

That is correct. In fact the Jack buffer size has to work with sr and
kr. What I have been using is sr 48000, kr 375, Jack buffer size 128.
That's already pretty good latency, about 3 milliseconds, even though
I'm not usually focussed on real-time performance.

Regards,
Mike

On Mon, Jan 24, 2011 at 3:16 PM, Victor Lazzarini
 wrote:
> They do matter and they can impose some further latencies. Generally, I try
> to match them. Mike's new jack IO opcodes
> work differently, though, and I think they depend solely on the Jack  buffer
> size.
> Victor
>
>
> On 24 Jan 2011, at 17:54, Aaron Krister Johnson wrote:
>
> Hey,
>
> just a quick question, since I wonder the same things sometimes....do the
> setting for -b and -B matter as far as using csound with jack are concerned?
> or does csound automagically hadnshake with jack's settings?
>
> AKJ
>
> On Sun, Jan 23, 2011 at 3:45 PM, Oeyvind Brandtsegg
>  wrote:
>>
>> Hm, my first thought is that it might be more trouble than it's worth,
>> unless you're trying to squeeze the last drops of performance out of a
>> slow computer (i.e.netbook or cellphone).
>>
>> Maybe you've already tried it, but using a lower kr will in many cases
>> improve performance significantly.
>> Also, if you have stuttering in realtime, it might be related to
>> poorly adjusted buffer sizes.
>> As a quick check, can you render your csd to file (e.g. -otest.wav)
>> and see if it's really the CPU time that is the bottleneck?
>> For example, if you have a score with a duration of one minute, and it
>> renders in 30 seconds when writing to file, then your number crunching
>> performance is fine, but the stuttering probebly stems from poorly
>> adjusted buffers.
>>
>> Sorry if this is too obvious, and I know, I'm not really answering
>> your question ... :-)
>> Oeyvind
>>
>> 2011/1/23 Christopher Charles :
>> > Hi.
>> >
>> > First Post. I'm using csound(linux) for a while and i'm starting to
>> > encounter stuttering when running it with moderately complex
>> > orchestras in realtime. I did most of the usual orchestra
>> > optimizations, but the calculations seem to be still a little bit too
>> > heavy to take on in realtime. Now I'd like to reduce the samplerate to
>> > maybe 32000 or maybe 22050 at least for realtime previewing, but my
>> > laptop soundchip does not support sample rates lower than 44.1khz. Is
>> > there a way in csound to render for a lower samplerate but play the
>> > result resampled for a higher rate (in realtime)? Or will i have to
>> > check for an external tool (via alsa or jack) that mimicks a soundcard
>> > supporting lower samplerates?
>> >
>> > Thanks in advance,
>> > .cc
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Okay, due to a dumb cpu scaling configuration bug on linux (my 2.4Ghz
core2 ran at max 1.6Ghz for over a year now) the rendering took 138s.
Now this one is resolved, it only takes 91s to render the .csd on
linux, which is still twice as much time as it takes on windows (46s).
Other simple benchmarks show no significant difference between being
run on windows and linux, so i think there are no external factors
involved besides the csound executable itself.
What else might affect the performance/efficiency of csound on linux?
Is there a set of recommended compile time options (what are the
compile time options for the windows build)?

Thanks in advance,
.cc


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Wow. nice to get rid of that cpu scaling then :-)

I agree that it looks like your csound has been compiled without
optimization enabled.
I use
gcc3opt='pentium4'
this seems to work nicely,
IIRC there is also a gcc4opt flag, but I haven't used that one.

Oeyvind

2011/1/25 Christopher Charles :
> Okay, due to a dumb cpu scaling configuration bug on linux (my 2.4Ghz
> core2 ran at max 1.6Ghz for over a year now) the rendering took 138s.
> Now this one is resolved, it only takes 91s to render the .csd on
> linux, which is still twice as much time as it takes on windows (46s).
> Other simple benchmarks show no significant difference between being
> run on windows and linux, so i think there are no external factors
> involved besides the csound executable itself.
> What else might affect the performance/efficiency of csound on linux?
> Is there a set of recommended compile time options (what are the
> compile time options for the windows build)?
>
> Thanks in advance,
> .cc
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

The compile time options are the same, since that depends on the CPU
architecture and not on the operating system.

I run on both Windows and Linux. I don't recall the specific speed
differences, but since I dual boot on exactly the same machine, I will
try some experiments soon (Windows 7 vs. Ubuntu 10.04).

Try to get closer to the lower-level audio layers, e.g. use plughw with ALSA.

Regards,
Mike

On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
 wrote:
> Wow. nice to get rid of that cpu scaling then :-)
>
> I agree that it looks like your csound has been compiled without
> optimization enabled.
> I use
> gcc3opt='pentium4'
> this seems to work nicely,
> IIRC there is also a gcc4opt flag, but I haven't used that one.
>
> Oeyvind
>
> 2011/1/25 Christopher Charles :
>> Okay, due to a dumb cpu scaling configuration bug on linux (my 2.4Ghz
>> core2 ran at max 1.6Ghz for over a year now) the rendering took 138s.
>> Now this one is resolved, it only takes 91s to render the .csd on
>> linux, which is still twice as much time as it takes on windows (46s).
>> Other simple benchmarks show no significant difference between being
>> run on windows and linux, so i think there are no external factors
>> involved besides the csound executable itself.
>> What else might affect the performance/efficiency of csound on linux?
>> Is there a set of recommended compile time options (what are the
>> compile time options for the windows build)?
>>
>> Thanks in advance,
>> .cc
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Maybe jackd knows how to get at ALSA from lower down in the driver
stack than you have been doing. It's still going through ALSA probably
so in reality, ALSA alone should be more efficient if you use it the
same way jackd does.

What with ALSA and OSS and PulseAudio, there can be many layers and
connections in the audio stack. This is what I am suggesting: cut to
as close to the bottom as you can.

Regards,
Mike

On Tue, Jan 25, 2011 at 10:32 AM, Aaron Krister Johnson
 wrote:
> Hi Michael,
>
> In my experience, performance with ALSA without jackd is nowhere near is
> tight as when jackd is running. I would recommend JACK, unless you know
> something I don't. The manual in fact recommends using JACK for RT when
> you're on Linux.
>
> AKJ
>
> On Tue, Jan 25, 2011 at 7:10 AM, Michael Gogins 
> wrote:
>>
>> The compile time options are the same, since that depends on the CPU
>> architecture and not on the operating system.
>>
>> I run on both Windows and Linux. I don't recall the specific speed
>> differences, but since I dual boot on exactly the same machine, I will
>> try some experiments soon (Windows 7 vs. Ubuntu 10.04).
>>
>> Try to get closer to the lower-level audio layers, e.g. use plughw with
>> ALSA.
>>
>> Regards,
>> Mike
>>
>> On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
>>  wrote:
>> > Wow. nice to get rid of that cpu scaling then :-)
>> >
>> > I agree that it looks like your csound has been compiled without
>> > optimization enabled.
>> > I use
>> > gcc3opt='pentium4'
>> > this seems to work nicely,
>> > IIRC there is also a gcc4opt flag, but I haven't used that one.
>> >
>> > Oeyvind
>> >
>> > 2011/1/25 Christopher Charles :
>> >> Okay, due to a dumb cpu scaling configuration bug on linux (my 2.4Ghz
>> >> core2 ran at max 1.6Ghz for over a year now) the rendering took 138s.
>> >> Now this one is resolved, it only takes 91s to render the .csd on
>> >> linux, which is still twice as much time as it takes on windows (46s).
>> >> Other simple benchmarks show no significant difference between being
>> >> run on windows and linux, so i think there are no external factors
>> >> involved besides the csound executable itself.
>> >> What else might affect the performance/efficiency of csound on linux?
>> >> Is there a set of recommended compile time options (what are the
>> >> compile time options for the windows build)?
>> >>
>> >> Thanks in advance,
>> >> .cc
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe csound"
>> >>
>> >>
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yeah I use lubuntu because lxde doesn't use pulse audio, I get good
performance out of alsa alone when my wifi is turned off and I'm
running a distro that doesn't include pulse audio, I'm running on a
little 900mgz celeron netbook.

On Tue, Jan 25, 2011 at 7:49 AM, Michael Gogins
 wrote:
> Maybe jackd knows how to get at ALSA from lower down in the driver
> stack than you have been doing. It's still going through ALSA probably
> so in reality, ALSA alone should be more efficient if you use it the
> same way jackd does.
>
> What with ALSA and OSS and PulseAudio, there can be many layers and
> connections in the audio stack. This is what I am suggesting: cut to
> as close to the bottom as you can.
>
> Regards,
> Mike
>
> On Tue, Jan 25, 2011 at 10:32 AM, Aaron Krister Johnson
>  wrote:
>> Hi Michael,
>>
>> In my experience, performance with ALSA without jackd is nowhere near is
>> tight as when jackd is running. I would recommend JACK, unless you know
>> something I don't. The manual in fact recommends using JACK for RT when
>> you're on Linux.
>>
>> AKJ
>>
>> On Tue, Jan 25, 2011 at 7:10 AM, Michael Gogins 
>> wrote:
>>>
>>> The compile time options are the same, since that depends on the CPU
>>> architecture and not on the operating system.
>>>
>>> I run on both Windows and Linux. I don't recall the specific speed
>>> differences, but since I dual boot on exactly the same machine, I will
>>> try some experiments soon (Windows 7 vs. Ubuntu 10.04).
>>>
>>> Try to get closer to the lower-level audio layers, e.g. use plughw with
>>> ALSA.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
>>>  wrote:
>>> > Wow. nice to get rid of that cpu scaling then :-)
>>> >
>>> > I agree that it looks like your csound has been compiled without
>>> > optimization enabled.
>>> > I use
>>> > gcc3opt='pentium4'
>>> > this seems to work nicely,
>>> > IIRC there is also a gcc4opt flag, but I haven't used that one.
>>> >
>>> > Oeyvind
>>> >
>>> > 2011/1/25 Christopher Charles :
>>> >> Okay, due to a dumb cpu scaling configuration bug on linux (my 2.4Ghz
>>> >> core2 ran at max 1.6Ghz for over a year now) the rendering took 138s.
>>> >> Now this one is resolved, it only takes 91s to render the .csd on
>>> >> linux, which is still twice as much time as it takes on windows (46s).
>>> >> Other simple benchmarks show no significant difference between being
>>> >> run on windows and linux, so i think there are no external factors
>>> >> involved besides the csound executable itself.
>>> >> What else might affect the performance/efficiency of csound on linux?
>>> >> Is there a set of recommended compile time options (what are the
>>> >> compile time options for the windows build)?
>>> >>
>>> >> Thanks in advance,
>>> >> .cc
>>> >>
>>> >>
>>> >> Send bugs reports to the Sourceforge bug tracker
>>> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >> Discussions of bugs and features can be posted here
>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> >> "unsubscribe csound"
>>> >>
>>> >>
>>> >
>>> >
>>> > Send bugs reports to the Sourceforge bug tracker
>>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> > Discussions of bugs and features can be posted here
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> > csound"
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I completely agree about too many choices, but that's the price one
pays for freedom -- like a whole aisle of detergent brands in the
supermarket.

I too have removed PulseAudio from my system.

Regards,
Mike

On Tue, Jan 25, 2011 at 12:32 PM, Aaron Krister Johnson
 wrote:
>
> PulseAudio is rotten to the core. You can remove it on any distro, but
> apparantly on Ubuntu it's a little more tricky. I got rid of it right away
> on my Arch system. 'pacman -R pulseaudio' or some such command---I forgot
> the package name proper...
>
> It's been a terrible decision by Linux distro people and desktop environment
> developers to even consider PulseAudio.
>
> Unfortunately, a problem plaguing Linux in general, and I love Linux, is the
> presence of too many choices; instead of making a few choices better in
> quality, developers branch off and try to reinvent the wheel. Why anyone
> would need another sound server when JACK ffor pro-audio purposes was
> already amazingly competent, and there was ESD, ARTS, for desktop
> needs,etc., is beyond me.
>
> AKJ
>
> On Tue, Jan 25, 2011 at 10:45 AM, Brian Redfern 
> wrote:
>>
>> Yeah I use lubuntu because lxde doesn't use pulse audio, I get good
>> performance out of alsa alone when my wifi is turned off and I'm
>> running a distro that doesn't include pulse audio, I'm running on a
>> little 900mgz celeron netbook.
>>
>> On Tue, Jan 25, 2011 at 7:49 AM, Michael Gogins
>>  wrote:
>> > Maybe jackd knows how to get at ALSA from lower down in the driver
>> > stack than you have been doing. It's still going through ALSA probably
>> > so in reality, ALSA alone should be more efficient if you use it the
>> > same way jackd does.
>> >
>> > What with ALSA and OSS and PulseAudio, there can be many layers and
>> > connections in the audio stack. This is what I am suggesting: cut to
>> > as close to the bottom as you can.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Jan 25, 2011 at 10:32 AM, Aaron Krister Johnson
>> >  wrote:
>> >> Hi Michael,
>> >>
>> >> In my experience, performance with ALSA without jackd is nowhere near
>> >> is
>> >> tight as when jackd is running. I would recommend JACK, unless you know
>> >> something I don't. The manual in fact recommends using JACK for RT when
>> >> you're on Linux.
>> >>
>> >> AKJ
>> >>
>> >> On Tue, Jan 25, 2011 at 7:10 AM, Michael Gogins
>> >> 
>> >> wrote:
>> >>>
>> >>> The compile time options are the same, since that depends on the CPU
>> >>> architecture and not on the operating system.
>> >>>
>> >>> I run on both Windows and Linux. I don't recall the specific speed
>> >>> differences, but since I dual boot on exactly the same machine, I will
>> >>> try some experiments soon (Windows 7 vs. Ubuntu 10.04).
>> >>>
>> >>> Try to get closer to the lower-level audio layers, e.g. use plughw
>> >>> with
>> >>> ALSA.
>> >>>
>> >>> Regards,
>> >>> Mike
>> >>>
>> >>> On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
>> >>>  wrote:
>> >>> > Wow. nice to get rid of that cpu scaling then :-)
>> >>> >
>> >>> > I agree that it looks like your csound has been compiled without
>> >>> > optimization enabled.
>> >>> > I use
>> >>> > gcc3opt='pentium4'
>> >>> > this seems to work nicely,
>> >>> > IIRC there is also a gcc4opt flag, but I haven't used that one.
>> >>> >
>> >>> > Oeyvind
>> >>> >
>> >>> > 2011/1/25 Christopher Charles :
>> >>> >> Okay, due to a dumb cpu scaling configuration bug on linux (my
>> >>> >> 2.4Ghz
>> >>> >> core2 ran at max 1.6Ghz for over a year now) the rendering took
>> >>> >> 138s.
>> >>> >> Now this one is resolved, it only takes 91s to render the .csd on
>> >>> >> linux, which is still twice as much time as it takes on windows
>> >>> >> (46s).
>> >>> >> Other simple benchmarks show no significant difference between
>> >>> >> being
>> >>> >> run on windows and linux, so i think there are no external factors
>> >>> >> involved besides the csound executable itself.
>> >>> >> What else might affect the performance/efficiency of csound on
>> >>> >> linux?
>> >>> >> Is there a set of recommended compile time options (what are the
>> >>> >> compile time options for the windows build)?
>> >>> >>
>> >>> >> Thanks in advance,
>> >>> >> .cc
>> >>> >>
>> >>> >>
>> >>> >> Send bugs reports to the Sourceforge bug tracker
>> >>> >>
>> >>> >>  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> >> Discussions of bugs and features can be posted here
>> >>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> >> "unsubscribe csound"
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > Send bugs reports to the Sourceforge bug tracker
>> >>> >
>> >>> >  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> > Discussions of bugs and features can be posted here
>> >>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> > "unsubscribe
>> >>> > csound"
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Michael Gogins
>> >>> Irreducible Productions
>> >>> http://www.michael-gogins.com
>> >>> Michael dot Gogins at gmail dot com
>> >>>
>> >>>
>> >>> Send bugs reports to the Sourceforge bug tracker
>> >>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> Discussions of bugs and features can be posted here
>> >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> "unsubscribe
>> >>> csound"
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Aaron Krister Johnson
>> >> http://www.akjmusic.com
>> >> http://www.untwelve.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Michael Gogins
>> > Irreducible Productions
>> > http://www.michael-gogins.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Most of these are pre-jackd, like artsd or esd, but pulse audio was
added so you could have basic sound card control. Jack is so much
better, but its for professional audio/music uses, its probably too
complex for the average audio user who just wants to listen to mp3.

On Tue, Jan 25, 2011 at 9:32 AM, Aaron Krister Johnson
 wrote:
>
> PulseAudio is rotten to the core. You can remove it on any distro, but
> apparantly on Ubuntu it's a little more tricky. I got rid of it right away
> on my Arch system. 'pacman -R pulseaudio' or some such command---I forgot
> the package name proper...
>
> It's been a terrible decision by Linux distro people and desktop environment
> developers to even consider PulseAudio.
>
> Unfortunately, a problem plaguing Linux in general, and I love Linux, is the
> presence of too many choices; instead of making a few choices better in
> quality, developers branch off and try to reinvent the wheel. Why anyone
> would need another sound server when JACK ffor pro-audio purposes was
> already amazingly competent, and there was ESD, ARTS, for desktop
> needs,etc., is beyond me.
>
> AKJ
>
> On Tue, Jan 25, 2011 at 10:45 AM, Brian Redfern 
> wrote:
>>
>> Yeah I use lubuntu because lxde doesn't use pulse audio, I get good
>> performance out of alsa alone when my wifi is turned off and I'm
>> running a distro that doesn't include pulse audio, I'm running on a
>> little 900mgz celeron netbook.
>>
>> On Tue, Jan 25, 2011 at 7:49 AM, Michael Gogins
>>  wrote:
>> > Maybe jackd knows how to get at ALSA from lower down in the driver
>> > stack than you have been doing. It's still going through ALSA probably
>> > so in reality, ALSA alone should be more efficient if you use it the
>> > same way jackd does.
>> >
>> > What with ALSA and OSS and PulseAudio, there can be many layers and
>> > connections in the audio stack. This is what I am suggesting: cut to
>> > as close to the bottom as you can.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Jan 25, 2011 at 10:32 AM, Aaron Krister Johnson
>> >  wrote:
>> >> Hi Michael,
>> >>
>> >> In my experience, performance with ALSA without jackd is nowhere near
>> >> is
>> >> tight as when jackd is running. I would recommend JACK, unless you know
>> >> something I don't. The manual in fact recommends using JACK for RT when
>> >> you're on Linux.
>> >>
>> >> AKJ
>> >>
>> >> On Tue, Jan 25, 2011 at 7:10 AM, Michael Gogins
>> >> 
>> >> wrote:
>> >>>
>> >>> The compile time options are the same, since that depends on the CPU
>> >>> architecture and not on the operating system.
>> >>>
>> >>> I run on both Windows and Linux. I don't recall the specific speed
>> >>> differences, but since I dual boot on exactly the same machine, I will
>> >>> try some experiments soon (Windows 7 vs. Ubuntu 10.04).
>> >>>
>> >>> Try to get closer to the lower-level audio layers, e.g. use plughw
>> >>> with
>> >>> ALSA.
>> >>>
>> >>> Regards,
>> >>> Mike
>> >>>
>> >>> On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
>> >>>  wrote:
>> >>> > Wow. nice to get rid of that cpu scaling then :-)
>> >>> >
>> >>> > I agree that it looks like your csound has been compiled without
>> >>> > optimization enabled.
>> >>> > I use
>> >>> > gcc3opt='pentium4'
>> >>> > this seems to work nicely,
>> >>> > IIRC there is also a gcc4opt flag, but I haven't used that one.
>> >>> >
>> >>> > Oeyvind
>> >>> >
>> >>> > 2011/1/25 Christopher Charles :
>> >>> >> Okay, due to a dumb cpu scaling configuration bug on linux (my
>> >>> >> 2.4Ghz
>> >>> >> core2 ran at max 1.6Ghz for over a year now) the rendering took
>> >>> >> 138s.
>> >>> >> Now this one is resolved, it only takes 91s to render the .csd on
>> >>> >> linux, which is still twice as much time as it takes on windows
>> >>> >> (46s).
>> >>> >> Other simple benchmarks show no significant difference between
>> >>> >> being
>> >>> >> run on windows and linux, so i think there are no external factors
>> >>> >> involved besides the csound executable itself.
>> >>> >> What else might affect the performance/efficiency of csound on
>> >>> >> linux?
>> >>> >> Is there a set of recommended compile time options (what are the
>> >>> >> compile time options for the windows build)?
>> >>> >>
>> >>> >> Thanks in advance,
>> >>> >> .cc
>> >>> >>
>> >>> >>
>> >>> >> Send bugs reports to the Sourceforge bug tracker
>> >>> >>
>> >>> >>  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> >> Discussions of bugs and features can be posted here
>> >>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> >> "unsubscribe csound"
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > Send bugs reports to the Sourceforge bug tracker
>> >>> >
>> >>> >  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> > Discussions of bugs and features can be posted here
>> >>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> > "unsubscribe
>> >>> > csound"
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Michael Gogins
>> >>> Irreducible Productions
>> >>> http://www.michael-gogins.com
>> >>> Michael dot Gogins at gmail dot com
>> >>>
>> >>>
>> >>> Send bugs reports to the Sourceforge bug tracker
>> >>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> Discussions of bugs and features can be posted here
>> >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> "unsubscribe
>> >>> csound"
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Aaron Krister Johnson
>> >> http://www.akjmusic.com
>> >> http://www.untwelve.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Michael Gogins
>> > Irreducible Productions
>> > http://www.michael-gogins.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

My take on Jack: Very well designed and written code that is too
difficult to use. For ordinary users there has to be something that is
set up to work "out of the box" and that is not too difficult for more
advanced users to work with or to undo for their own purposes. And I
don't think that would be too hard to do. Audio apps, on startup, by
default could connect themselves to a Jack mixer. Jackd could be
configurable by advanced users not to accept such requests.

My 2 cents.

Regards,
Mike

On Tue, Jan 25, 2011 at 4:43 PM, Brian Redfern  wrote:
> Most of these are pre-jackd, like artsd or esd, but pulse audio was
> added so you could have basic sound card control. Jack is so much
> better, but its for professional audio/music uses, its probably too
> complex for the average audio user who just wants to listen to mp3.
>
> On Tue, Jan 25, 2011 at 9:32 AM, Aaron Krister Johnson
>  wrote:
>>
>> PulseAudio is rotten to the core. You can remove it on any distro, but
>> apparantly on Ubuntu it's a little more tricky. I got rid of it right away
>> on my Arch system. 'pacman -R pulseaudio' or some such command---I forgot
>> the package name proper...
>>
>> It's been a terrible decision by Linux distro people and desktop environment
>> developers to even consider PulseAudio.
>>
>> Unfortunately, a problem plaguing Linux in general, and I love Linux, is the
>> presence of too many choices; instead of making a few choices better in
>> quality, developers branch off and try to reinvent the wheel. Why anyone
>> would need another sound server when JACK ffor pro-audio purposes was
>> already amazingly competent, and there was ESD, ARTS, for desktop
>> needs,etc., is beyond me.
>>
>> AKJ
>>
>> On Tue, Jan 25, 2011 at 10:45 AM, Brian Redfern 
>> wrote:
>>>
>>> Yeah I use lubuntu because lxde doesn't use pulse audio, I get good
>>> performance out of alsa alone when my wifi is turned off and I'm
>>> running a distro that doesn't include pulse audio, I'm running on a
>>> little 900mgz celeron netbook.
>>>
>>> On Tue, Jan 25, 2011 at 7:49 AM, Michael Gogins
>>>  wrote:
>>> > Maybe jackd knows how to get at ALSA from lower down in the driver
>>> > stack than you have been doing. It's still going through ALSA probably
>>> > so in reality, ALSA alone should be more efficient if you use it the
>>> > same way jackd does.
>>> >
>>> > What with ALSA and OSS and PulseAudio, there can be many layers and
>>> > connections in the audio stack. This is what I am suggesting: cut to
>>> > as close to the bottom as you can.
>>> >
>>> > Regards,
>>> > Mike
>>> >
>>> > On Tue, Jan 25, 2011 at 10:32 AM, Aaron Krister Johnson
>>> >  wrote:
>>> >> Hi Michael,
>>> >>
>>> >> In my experience, performance with ALSA without jackd is nowhere near
>>> >> is
>>> >> tight as when jackd is running. I would recommend JACK, unless you know
>>> >> something I don't. The manual in fact recommends using JACK for RT when
>>> >> you're on Linux.
>>> >>
>>> >> AKJ
>>> >>
>>> >> On Tue, Jan 25, 2011 at 7:10 AM, Michael Gogins
>>> >> 
>>> >> wrote:
>>> >>>
>>> >>> The compile time options are the same, since that depends on the CPU
>>> >>> architecture and not on the operating system.
>>> >>>
>>> >>> I run on both Windows and Linux. I don't recall the specific speed
>>> >>> differences, but since I dual boot on exactly the same machine, I will
>>> >>> try some experiments soon (Windows 7 vs. Ubuntu 10.04).
>>> >>>
>>> >>> Try to get closer to the lower-level audio layers, e.g. use plughw
>>> >>> with
>>> >>> ALSA.
>>> >>>
>>> >>> Regards,
>>> >>> Mike
>>> >>>
>>> >>> On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
>>> >>>  wrote:
>>> >>> > Wow. nice to get rid of that cpu scaling then :-)
>>> >>> >
>>> >>> > I agree that it looks like your csound has been compiled without
>>> >>> > optimization enabled.
>>> >>> > I use
>>> >>> > gcc3opt='pentium4'
>>> >>> > this seems to work nicely,
>>> >>> > IIRC there is also a gcc4opt flag, but I haven't used that one.
>>> >>> >
>>> >>> > Oeyvind
>>> >>> >
>>> >>> > 2011/1/25 Christopher Charles :
>>> >>> >> Okay, due to a dumb cpu scaling configuration bug on linux (my
>>> >>> >> 2.4Ghz
>>> >>> >> core2 ran at max 1.6Ghz for over a year now) the rendering took
>>> >>> >> 138s.
>>> >>> >> Now this one is resolved, it only takes 91s to render the .csd on
>>> >>> >> linux, which is still twice as much time as it takes on windows
>>> >>> >> (46s).
>>> >>> >> Other simple benchmarks show no significant difference between
>>> >>> >> being
>>> >>> >> run on windows and linux, so i think there are no external factors
>>> >>> >> involved besides the csound executable itself.
>>> >>> >> What else might affect the performance/efficiency of csound on
>>> >>> >> linux?
>>> >>> >> Is there a set of recommended compile time options (what are the
>>> >>> >> compile time options for the windows build)?
>>> >>> >>
>>> >>> >> Thanks in advance,
>>> >>> >> .cc
>>> >>> >>
>>> >>> >>
>>> >>> >> Send bugs reports to the Sourceforge bug tracker
>>> >>> >>
>>> >>> >>  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >>> >> Discussions of bugs and features can be posted here
>>> >>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> >>> >> "unsubscribe csound"
>>> >>> >>
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> > Send bugs reports to the Sourceforge bug tracker
>>> >>> >
>>> >>> >  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >>> > Discussions of bugs and features can be posted here
>>> >>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> >>> > "unsubscribe
>>> >>> > csound"
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Michael Gogins
>>> >>> Irreducible Productions
>>> >>> http://www.michael-gogins.com
>>> >>> Michael dot Gogins at gmail dot com
>>> >>>
>>> >>>
>>> >>> Send bugs reports to the Sourceforge bug tracker
>>> >>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >>> Discussions of bugs and features can be posted here
>>> >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> >>> "unsubscribe
>>> >>> csound"
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Aaron Krister Johnson
>>> >> http://www.akjmusic.com
>>> >> http://www.untwelve.org
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Michael Gogins
>>> > Irreducible Productions
>>> > http://www.michael-gogins.com
>>> > Michael dot Gogins at gmail dot com
>>> >
>>> >
>>> > Send bugs reports to the Sourceforge bug tracker
>>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> > Discussions of bugs and features can be posted here
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> > csound"
>>> >
>>> >
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Well for the average user who uses standard ubuntu and doesn't do
audio work its fine. It took me a while to learn jack, I was using the
jazz++ sequencer at one time, been doing linux audio since 1998. Linux
audio/music apps have come a long way, now commercial companies like
Pianoteq support linux audio by developing jack enabled versions of
their audio software that used to only work with mac or windows.

On Tue, Jan 25, 2011 at 2:23 PM, Aaron Krister Johnson
 wrote:
> My take on it is this: nothing in Linux works "out of the box" all that
> often :) I love it, been using it since '97, but it's not an out-of-the-box
> OS. But man, it's a great performer when it's all in place, better than any.
>
> PulseAudio, last I checked was even called by its developers "the thing that
> breaks your computer sound system"
>
> AKJ
>
> On Tue, Jan 25, 2011 at 3:55 PM, Michael Gogins 
> wrote:
>>
>> My take on Jack: Very well designed and written code that is too
>> difficult to use. For ordinary users there has to be something that is
>> set up to work "out of the box" and that is not too difficult for more
>> advanced users to work with or to undo for their own purposes. And I
>> don't think that would be too hard to do. Audio apps, on startup, by
>> default could connect themselves to a Jack mixer. Jackd could be
>> configurable by advanced users not to accept such requests.
>>
>> My 2 cents.
>>
>> Regards,
>> Mike
>>
>> On Tue, Jan 25, 2011 at 4:43 PM, Brian Redfern 
>> wrote:
>> > Most of these are pre-jackd, like artsd or esd, but pulse audio was
>> > added so you could have basic sound card control. Jack is so much
>> > better, but its for professional audio/music uses, its probably too
>> > complex for the average audio user who just wants to listen to mp3.
>> >
>> > On Tue, Jan 25, 2011 at 9:32 AM, Aaron Krister Johnson
>> >  wrote:
>> >>
>> >> PulseAudio is rotten to the core. You can remove it on any distro, but
>> >> apparantly on Ubuntu it's a little more tricky. I got rid of it right
>> >> away
>> >> on my Arch system. 'pacman -R pulseaudio' or some such command---I
>> >> forgot
>> >> the package name proper...
>> >>
>> >> It's been a terrible decision by Linux distro people and desktop
>> >> environment
>> >> developers to even consider PulseAudio.
>> >>
>> >> Unfortunately, a problem plaguing Linux in general, and I love Linux,
>> >> is the
>> >> presence of too many choices; instead of making a few choices better in
>> >> quality, developers branch off and try to reinvent the wheel. Why
>> >> anyone
>> >> would need another sound server when JACK ffor pro-audio purposes was
>> >> already amazingly competent, and there was ESD, ARTS, for desktop
>> >> needs,etc., is beyond me.
>> >>
>> >> AKJ
>> >>
>> >> On Tue, Jan 25, 2011 at 10:45 AM, Brian Redfern
>> >> 
>> >> wrote:
>> >>>
>> >>> Yeah I use lubuntu because lxde doesn't use pulse audio, I get good
>> >>> performance out of alsa alone when my wifi is turned off and I'm
>> >>> running a distro that doesn't include pulse audio, I'm running on a
>> >>> little 900mgz celeron netbook.
>> >>>
>> >>> On Tue, Jan 25, 2011 at 7:49 AM, Michael Gogins
>> >>>  wrote:
>> >>> > Maybe jackd knows how to get at ALSA from lower down in the driver
>> >>> > stack than you have been doing. It's still going through ALSA
>> >>> > probably
>> >>> > so in reality, ALSA alone should be more efficient if you use it the
>> >>> > same way jackd does.
>> >>> >
>> >>> > What with ALSA and OSS and PulseAudio, there can be many layers and
>> >>> > connections in the audio stack. This is what I am suggesting: cut to
>> >>> > as close to the bottom as you can.
>> >>> >
>> >>> > Regards,
>> >>> > Mike
>> >>> >
>> >>> > On Tue, Jan 25, 2011 at 10:32 AM, Aaron Krister Johnson
>> >>> >  wrote:
>> >>> >> Hi Michael,
>> >>> >>
>> >>> >> In my experience, performance with ALSA without jackd is nowhere
>> >>> >> near
>> >>> >> is
>> >>> >> tight as when jackd is running. I would recommend JACK, unless you
>> >>> >> know
>> >>> >> something I don't. The manual in fact recommends using JACK for RT
>> >>> >> when
>> >>> >> you're on Linux.
>> >>> >>
>> >>> >> AKJ
>> >>> >>
>> >>> >> On Tue, Jan 25, 2011 at 7:10 AM, Michael Gogins
>> >>> >> 
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> The compile time options are the same, since that depends on the
>> >>> >>> CPU
>> >>> >>> architecture and not on the operating system.
>> >>> >>>
>> >>> >>> I run on both Windows and Linux. I don't recall the specific speed
>> >>> >>> differences, but since I dual boot on exactly the same machine, I
>> >>> >>> will
>> >>> >>> try some experiments soon (Windows 7 vs. Ubuntu 10.04).
>> >>> >>>
>> >>> >>> Try to get closer to the lower-level audio layers, e.g. use plughw
>> >>> >>> with
>> >>> >>> ALSA.
>> >>> >>>
>> >>> >>> Regards,
>> >>> >>> Mike
>> >>> >>>
>> >>> >>> On Tue, Jan 25, 2011 at 7:31 AM, Oeyvind Brandtsegg
>> >>> >>>  wrote:
>> >>> >>> > Wow. nice to get rid of that cpu scaling then :-)
>> >>> >>> >
>> >>> >>> > I agree that it looks like your csound has been compiled without
>> >>> >>> > optimization enabled.
>> >>> >>> > I use
>> >>> >>> > gcc3opt='pentium4'
>> >>> >>> > this seems to work nicely,
>> >>> >>> > IIRC there is also a gcc4opt flag, but I haven't used that one.
>> >>> >>> >
>> >>> >>> > Oeyvind
>> >>> >>> >
>> >>> >>> > 2011/1/25 Christopher Charles :
>> >>> >>> >> Okay, due to a dumb cpu scaling configuration bug on linux (my
>> >>> >>> >> 2.4Ghz
>> >>> >>> >> core2 ran at max 1.6Ghz for over a year now) the rendering took
>> >>> >>> >> 138s.
>> >>> >>> >> Now this one is resolved, it only takes 91s to render the .csd
>> >>> >>> >> on
>> >>> >>> >> linux, which is still twice as much time as it takes on windows
>> >>> >>> >> (46s).
>> >>> >>> >> Other simple benchmarks show no significant difference between
>> >>> >>> >> being
>> >>> >>> >> run on windows and linux, so i think there are no external
>> >>> >>> >> factors
>> >>> >>> >> involved besides the csound executable itself.
>> >>> >>> >> What else might affect the performance/efficiency of csound on
>> >>> >>> >> linux?
>> >>> >>> >> Is there a set of recommended compile time options (what are
>> >>> >>> >> the
>> >>> >>> >> compile time options for the windows build)?
>> >>> >>> >>
>> >>> >>> >> Thanks in advance,
>> >>> >>> >> .cc
>> >>> >>> >>
>> >>> >>> >>
>> >>> >>> >> Send bugs reports to the Sourceforge bug tracker
>> >>> >>> >>
>> >>> >>> >>  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> >>> >> Discussions of bugs and features can be posted here
>> >>> >>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> >>> >> "unsubscribe csound"
>> >>> >>> >>
>> >>> >>> >>
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > Send bugs reports to the Sourceforge bug tracker
>> >>> >>> >
>> >>> >>> >  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> >>> > Discussions of bugs and features can be posted here
>> >>> >>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> >>> > "unsubscribe
>> >>> >>> > csound"
>> >>> >>> >
>> >>> >>> >
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>> Michael Gogins
>> >>> >>> Irreducible Productions
>> >>> >>> http://www.michael-gogins.com
>> >>> >>> Michael dot Gogins at gmail dot com
>> >>> >>>
>> >>> >>>
>> >>> >>> Send bugs reports to the Sourceforge bug tracker
>> >>> >>>
>> >>> >>>  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> >>> Discussions of bugs and features can be posted here
>> >>> >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> >>> "unsubscribe
>> >>> >>> csound"
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Aaron Krister Johnson
>> >>> >> http://www.akjmusic.com
>> >>> >> http://www.untwelve.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Michael Gogins
>> >>> > Irreducible Productions
>> >>> > http://www.michael-gogins.com
>> >>> > Michael dot Gogins at gmail dot com
>> >>> >
>> >>> >
>> >>> > Send bugs reports to the Sourceforge bug tracker
>> >>> >
>> >>> >  https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> > Discussions of bugs and features can be posted here
>> >>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> > "unsubscribe
>> >>> > csound"
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> Send bugs reports to the Sourceforge bug tracker
>> >>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >>> Discussions of bugs and features can be posted here
>> >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>> "unsubscribe
>> >>> csound"
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Aaron Krister Johnson
>> >> http://www.akjmusic.com
>> >> http://www.untwelve.org
>> >>
>> >>
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"