LinuxMusicians

It has to be said that Ubuntu Studio is a different beast from stock Ubuntu. There is no unity & all the associated nonsense.

In a similar vein, I am currently using Bodhi which, again, is Ubuntu based. Though an early adopter, I feel I can no longer use stock Ubuntu on usability issues alone. However, there are ways to get the benefits without the drawbacks.

English Guy wrote:feel I can no longer use stock Ubuntu on usability issues alone. However, there are ways to get the benefits without the drawbacks.

I feel the same way. I've used Linux Mint for about 3 years now, and have up until recently used it as the base of my kxstudio desktop. Last month though I split my regular desktop and audio workstation. I'm running Mint 13 for my day to day operations, and Peppermint OS Three with KXStudio for my audio work. With the right desktop and tweeks things run just fine!

The whole "spyware" thing is a complete side issue. Spyware? I don't even run Unity. It's an issue if the conversation is about who is Shuttleworth, what is his organisation like, what is the future, will the ubuntu desktop continue to be freely changeable, and so on.

Heck, I am just a guy who found an easy-to-live-with alternative to Windows (XP) and want's his desktop and way of working, whether it is with audio or the internet, to look roughly but configurably the same. The fact that I'm also a retired Unix systems manager means, yes, I can cope with a bit of techie stuff, and then some more, but also that it used to be the day job, and I can do when I need, but don't like having to do it from square one to get something running. And I'm sufficiently tired of techiness not to want to learn a new suite of installation/administration tools. Flexibility and an open mind are admirable, but I'm old and imperfect!

As such, I have strong feelings about Shuttleworth's view of the future, which I don't, personally, believe is going to help Linux on the more general desktop at all --- but that's a conversation for the Linix forums, and, for now, MATE is there. And Mint may be the next stop.

Ubuntu Spyware: What to Do? Posted by Richard Stallman at Dec 07, 2012

Moderation by raboof: removed verbatim-quoted text, click the link for the article

j_e_f_f_g wrote:

raboof wrote:back it up with some kind of easy to reproduce benchmarking suite that tests the stuff we care about

Regardless of whether it was or wasn't easy to setup, that youtube comparison video is a perfectly valid benchmarking. He installed each contender in its intended "out of the box" configuration (ie, he didn't deliberately cripple a contender), run on the exact same hardware, using the same test app, with the same audio configuration (ie, jack with the same settings), and obtained results using the same software measurement tool (ie, jack's own latency and overrun diagnostics). Bottom line is that his methodology is proper. It's a valid, accurate test of audio performance (where he focused on that).

Sure! It's just in my opinion such a benchmark should be a starting point, not an end-result. Anyway, I've described what I would have liked to see in such a benchmark above, won't bore you by repeating it here.

the results shattered some illusions, thereby upsetting people who are inclined to be upset by such. But that's irrelevant to the test results

To be quite honest I don't see a lot of shattered illusions or upset people in this thread. Some frustration with the way it was presented, yes.

I imagine an easy-to-use, real-world latency/overrun test app would be one that uses alsa to directly open the card's hardware interface (no dmix or plug, and with buffering set by the app).

That would be a very useful component in such a suite. The suite would also have to contains more high-level tests (to the point of something like 'open this complicated project in ardour and play it, count the xruns'). When one distro performs up-to-par in the tool you describe, but not when running the more high-level test, that tells us something about where to look.

I'd have no problem writing such a tool, and would be willing to do so if someone is seriously committed to installing/testing several distros (from various bases). But I get the impression that the OP was disillusioned by that initial benchmark test, assumed the methodology was flawed, and thought that he could produce different results with his own test.

I won't go into amateur-psychology guesses as to why i2productions wanted to perform his own benchmarks, but I'd welcome them in any case.

Then when those assumptions turned out to be incorrect, the reaction changed to "I don't care my distro has worse audio performance. All that matters is that it's not Windows. And can't we all just stop saying that something has an advantage over ubuntu because somehow, someway, in my mind that's tantamount to declaring war on linux, and you don't want to be unpatriotic, do you?".

I really don't see that (and I'm not sure discussing it is useful - I considered leaving this reply out entirely but here it is, so there ya go).

you're exaggerating the impact Ubuntu's focus has on the possibility of tweaking it to perform well.

Are you implying that the creators of those 3 ubuntu distros don't know how to tweak ubuntu so that it runs as well as other distro bases? Because the only other possibility is that the ubuntu base itself needs significantly more modifications (in order to "come up to speed") than even the maintainers of ubuntu-based audio distros have done.

Given the benchmark results presented so far: yes, I am. And that's in no way meant as condescending to those creators - performance tuning is Hard with a capital H, and it certainly isn't the only ingredient to a musicians' distro. For example probably many users will love FalkTX's usability/productivity work, or his awesome support and quick response to feature requests. Even if he didn't squeeze the very last drop of performance out of the distro. For them KXStudio would still be an absolutely valid choice.

Be careful when arguing hypotheticals because it sometimes invites even more detrimental possibilities than whatever it is your hypothetical seeks to counteract.

I'm sorry, I have no clue what you're trying to say here .

GMaq wrote:The key here is that Studio 13.37 was booting with the 'toram' parameter and the others weren't so that alone accounts for a lot of speed difference

Do you think 'toram' accounts for the difference in both boot speed and latency? In theory I'd expect it to improve boot speed (which I don't care about much) but not latency (which I care about a lot). Would be interested to see further testing there.

GMaq wrote:Oh and BTW our fellow forum members nick is l0wt3ch (not l0witch or l0wl1fe)... Sorry, I certainly don't agree with him all the time either but c'mon this kind of stuff is a bit Kindergarten. Nobody should have their username mangled like that...

Couldn't agree more.

raboof wrote:

GMaq wrote:The key here is that Studio 13.37 was booting with the 'toram' parameter and the others weren't so that alone accounts for a lot of speed difference

Do you think 'toram' accounts for the difference in both boot speed and latency? In theory I'd expect it to improve boot speed (which I don't care about much) but not latency (which I care about a lot). Would be interested to see further testing there.

GMaq wrote:Oh and BTW our fellow forum members nick is l0wt3ch (not l0witch or l0wl1fe)... Sorry, I certainly don't agree with him all the time either but c'mon this kind of stuff is a bit Kindergarten. Nobody should have their username mangled like that...

Couldn't agree more.

Hi raboof,

I have to confess my deep system knowledge of Linux is maddeningly spotty so I am a little hazy on what actually happens as far as the decompression of squashfs when a LiveCD/DVD is booted with 'toram'. For instance all Live Media runs to a degree in the hosts RAM but I believe the entire OS runs in RAM with the 'toram' option, if the whole OS decompresses and runs in RAM than I would think any I/O latencies including JACK would be potentially vastly improved.

I'm guessing that l0wt3ch would rather not divulge his 'trade secrets' but I may try using toram with AV Linux just to see what actually happens, with the SLiM/LXDE DE it might actually be possible on my Desktop here with 4G of RAM. I don't know if everyone read it or not but at the end of the Video comparison thread l0wt3ch posted that his previous project 'Studio 4' in the same comparison had 24Xruns but I am not certain what the differences in booting methods are between Studio 13.37 and Studio 4.

GMaq wrote:

raboof wrote:

GMaq wrote:The key here is that Studio 13.37 was booting with the 'toram' parameter and the others weren't so that alone accounts for a lot of speed difference

Do you think 'toram' accounts for the difference in both boot speed and latency? In theory I'd expect it to improve boot speed (which I don't care about much) but not latency (which I care about a lot). Would be interested to see further testing there.

I believe the entire OS runs in RAM with the 'toram' option, if the whole OS decompresses and runs in RAM than I would think any I/O latencies including JACK would be potentially vastly improved.

(I guess I should have written 'xruns' instead of 'latency' above, though the difference seems moot for this particular discussion)

As far as I understand:

• the kernel itself is always loaded into RAM
• the 'toram' option moves some of the userland to RAM, too
• xruns are what happens when the JACK-based applications' process() methods don't return in time
• the thread in which the process() methods are called is given chrt priority over 'normal' threads
• the process() methods are not allowed to perform any system calls that may cause I/O or (other) blocking

If this is accurate, I'd say 'toram' would not prevent any xruns, because the process() methods of JACK-based applications don't touch the userland that was moved to RAM anyway. I'd be happy if someone could explain when I'm misunderstanding things though - this is not unlikely .

doesn't make sense loading an os to ram would lead to less xruns

it depends on system services loaded in the background

I can run EASILY hydrogen and jack with 16 frames/period and 2 periods/buffer on my Arch install qith 0 x-runs, and nothing is loaded to ram. I'm sure I could lower but I haven't tested it.

Capoeira wrote:it depends on system services loaded in the background

But that too doesn't seem to make much sense to me either:

• those system services are 'just processes'
• they're not running with chrt privileges
• JACK's thread that executes the process() methods does run with chrt privileges

... so JACK's processing thread should always pre-empt those services - which means those shouldn't be allowed to cause xrun's, right? It's been a while since I've been so deep into internals, but it's never stopped fascinating me.

raboof wrote:

Capoeira wrote:it depends on system services loaded in the background

But that too doesn't seem to make much sense to me either:

• those system services are 'just processes'
• they're not running with chrt privileges
• JACK's thread that executes the process() methods does run with chrt privileges

... so JACK's processing thread should always pre-empt those services - which means those shouldn't be allowed to cause xrun's, right? It's been a while since I've been so deep into internals, but it's never stopped fascinating me.

can't explain it, it's an observation.

2 possible thoughts I have

1st: DSP-load doesn't relate 100% to CPU load (I never understood this)
2nd: If a jack process has the priority and doesn't use 100% of CPU the other processes will use the CPU. Perhaps it like an ambulance with a siren. It has priority on the road, but it's slower if there are cars on the road and way faster when the road is empty.
I don't know.

Perhaps I install gnome with gdm some day to compare. (yes I think even the display manager has impact; I use Slim + E17)

Capoeira wrote:I can run EASILY hydrogen and jack with 16 frames/period and 2 periods/buffer on my Arch install qith 0 x-runs, and nothing is loaded to ram. I'm sure I could lower but I haven't tested it.

Really? Well, that is something. In my tests I only set the frames/period at 64, but if you can set it lower than 16, that is truly amazing.

You must be a lot smarter than I gave you credit for.

l0wt3ch wrote:

Capoeira wrote:I can run EASILY hydrogen and jack with 16 frames/period and 2 periods/buffer on my Arch install qith 0 x-runs, and nothing is loaded to ram. I'm sure I could lower but I haven't tested it.

Really? Well, that is something. In my tests I only set the frames/period at 64, but if you can set it lower than 16, that is truly amazing.

You must be a lot smarter than I gave you credit for.

What's in the vid? some drumnotes running in hydrogen?
I just tested this with 8 frames/period with no xruns. Lower then 8 frames/period jack won't start

It's like I said, I was always eviting background services. for example, I even evit software which installs gvfs.

I thought you weren't going to talk to me anymore.

What happened to that?

l0wt3ch wrote:I thought you weren't going to talk to me anymore.

What happened to that?

lol
somebody is always talking to you anyways.