Second positive reaction to 64 Studio
|
| Author | Content |
|---|---|
| Steven_Rosenber Jun 19, 2009 10:54 PM EDT |
Nice review by @tuxchick of 64 Studio (with a bit of PCLinuxOS thrown in). I do a bit of multimedia myself, and I'm glad somebody else is doing the heavy lifting for me (and I await the Linux audio-production book) |
| mjeffer Jun 20, 2009 2:25 AM EDT |
I have no comment on whether 64 Studio or PCLinuxOS are better or not as I've never used either...but that was just a HORRIBLE article. I would have liked a slightly in depth review of either or one of them. As it is, he doesn't mention PCLinuxOS other than saying he was thinking of wiping Ubuntu off the dual boot. All I got out of the whole thing was that audacity was snappier on 64 Studio than on Ubuntu. |
| nikkels Jun 20, 2009 4:30 AM EDT |
--------->>>As it is, he doesn't mention PCLinuxOS other than saying he was thinking of wiping Ubuntu off the dual boot. ---I have PCLinuxOS already for 3 years on my computer. It had Kubuntu on at the time. I never regretted it. I still test every Kununtu which comes out, but so far....No thanks. As for 64 studio.........>> I just finished the download :-) btw: pclos isn't to great for serious music/sound work. For just your mp3 s etc, it's OK, but anything professional......HMM, some work need to be done before you can start of At least on THIS computer Hope 64 studio cures that little ilness |
| cabreh Jun 20, 2009 5:21 AM EDT |
Last I looked 64 Studio is based on Ubuntu. Now I would be very surprised if Audacity wasn't snappier running under a Real-Time kernel (64 Studio) compared to a standard kernel ((K)(U)(u)buntu). Does anyone really find this surprising? |
| nikkels Jun 20, 2009 7:51 AM EDT |
No, not surprisingly at all. It was, for a while, a complaint on pclos. I don't think a rt-kernel is available now, but It was mentioned on the forum that one is needed |
| tuxchick Jun 20, 2009 2:18 PM EDT |
A realtime kernel has little to do with software performance, such as how fast Audacity opens, or how fast you can scroll the waveform display of a large multi-track audio file, or zoom in and out, or apply effects. The only thing it affects is the priority given to tasks by the kernel scheduler. Tasks related to audio recording are given highest priorities, so rt kernels mainly affects latency when you're recording. You can use any Linux distribution for audio recording, with a few tweaks to get latency down to where it needs to be. This is an old but good article on latency, scheduling, and pre-emption:
http://www.linuxjournal.com/article/8041 Audacity on stock PCLinuxOS runs great. Combined with JACK it even gets latency down to acceptable levels. PCLinuxOS on my Thinkpad makes a great little portable recording studio for interviews, podcasts, and two-channel music recordings. Once you have made your recordings you can edit them on any Linux system; you don't need a low-latency kernel for post-production. K/Ubuntu's performance was so bad I couldn't do that. 64 Studio is not based on Ubuntu. http://www.64studio.com/node/959 I am curious to know what 64 Studio and PCLinuxOS are doing to make overall performance so much better, and why Ubuntu is so lethargic on the same machines. I've gotten quite a few emails from readers with similar experiences. Yeah I know, I should have crammed a book into a single article. Sorry. |
| dinotrac Jun 20, 2009 2:58 PM EDT |
TC - You know so much more than I do about so many things IT and computing, so I am truly loath to correct you about anything, but.... I think you may have the essence of real-time computing wrong. Real-time computing isn't defined by its ability to prioritize processes. Decidedly non-real-time mainframes could prioritize any process to within an inch of its life. I spent years doing that very thing. I even -- good gravy -- designed a real-time system that ran on those non-real-time mainframes. Here's the skinny about real-time: Real time systems guarantee that no process will run longer than a given period of time. If they do not complete on their own, they are terminated. Lots of applications would prefer to kill something that has run too long to be useful (in my real-time on the mainframe system, we were switching telephone calls). PS - FWIW -- my real-time system was real-time only by cheating. We let the phone company kill it after x time. yeah -- it hung on for however many milliseconds on our system, but I won't tell if you won't. |
| tuxchick Jun 20, 2009 11:38 PM EDT |
Thanks dino, I've read reams of docs and talked to kernel devs, and still had the wrong idea. That's the best and shortest explanation I've seen. |
| cabreh Jun 21, 2009 6:40 AM EDT |
@TC Did you post the wrong link to say 64 Studio is NOT based on Ubuntu? After all Hardy is an Ubuntu distibution, The Software update screenshot definately says Ubuntu on it. Did I quit reading too soon? Or have I missed something here? |
| rijelkentaurus Jun 21, 2009 7:05 AM EDT |
The initial boot screen is Debian. EDIT: Wait, I tried version 2.0, not the newest one. |
| jdixon Jun 21, 2009 11:06 AM EDT |
> Real time systems guarantee that no process will run longer than a given period of time. My understanding was that real time systems offered a guaranteed response time to events, The exact time varies with the architecture, but the key is that it's guaranteed. Obviously there are multiple definitions of the term. |
| cabreh Jun 21, 2009 1:16 PM EDT |
@jdixon In as far as hardware controllers and such are concerned you are correct. A real time kernel guarantees a fixed response time-frame. This is required for hardware, time sensitive inputs. This is the type of kernel employed for 64 Studio to guarantee specific response times for sound recordings. |
| jdixon Jun 21, 2009 1:58 PM EDT |
> In as far as hardware controllers and such are concerned you are correct. Thanks, cabreh. That matches my recollections from my old OS-9 days. |
| tuxchick Jun 21, 2009 4:12 PM EDT |
re: if 64 Studio is Ubuntu-based or not, the fine article states: http://www.64studio.com/node/959 "This is a bit of a fine line... 64 Studio 3.0 is based on... 64 studio, being put together with the PDK tool, and cutting edge multimedia packages built and/or backported by our own in-house official Debian developer.... "Effectively we are just using the day to day packages from Ubuntu, and the Hot Stuff is 64 Studio.com backports / packages from Debian sources." There is more, it's worth reading the whole thread to get the complete picture. Whatever they are doing, I love it. |
| dinotrac Jun 21, 2009 7:12 PM EDT |
jdixon - Ummm.... That's another way of saying what I said. The only way to guarantee response time is to kill something that doesn't end within the window. Therefore, the true determinant of a real-time system is that it kills any task that does not complete in time. |
| jdixon Jun 21, 2009 9:06 PM EDT |
> The only way to guarantee response time is to kill something that doesn't end within the window. Well, OS-9 had some type of guaranteed interrupt response time, which is not quite the same thing. But I agree that if you have a fast enough processor, they're pretty close approximations of each other. Of course, OS-9 was designed to run on the MC6809, which is hardly a fast processor by today's standards. |
| dinotrac Jun 21, 2009 10:48 PM EDT |
jdixon - That is why you have to kill long runners. Not only are events that fail to finish in the window likely to be useless, they will tie up resources needed by tasks that are trying to complete in their alloted time, increasing the likelihood that more tasks will fail to complete as they should. |
| gus3 Jun 21, 2009 11:11 PM EDT |
Okay, dino, is there any valid difference between "hard real time" and "soft real time"? |
| dinotrac Jun 22, 2009 3:18 PM EDT |
gus3 - I could be wrong about this, but, my understanding is that "soft" real-time systems aren't quite real-time in the sense of but perform well enough to meet the need at hand. For example: Let's imagine that you have something that must be responded to appropriately within 500ms. Instead of using a real-time OS, you do a little modeling. You discover that, under the conditions you need, that 99.8% of all processes will complete within your window and that you can handle the 0.2% misses in a way that doesn't hurt anything. You will have achieved real-time performance without a real-time system. |
| gus3 Jun 22, 2009 4:05 PM EDT |
Okay, here's my understanding: "Hard real time" means, if a signal is not handled within its time limit, the results will be catastrophic, anything from program failure to equipment damage to human injury or death. It has nothing to do with the time limit imposed. Example: furnace temperature sensing. Failure to sense temperature can cause structural fire and human death, although its time limit could go as high as ten minutes or more. But once the limit is exceeded, there needs to be a warning of system failure and loss of control. "Soft real time" means that the results, while erroneous or degraded, are not catastrophic. Example: monitoring average motor speed for maintenance purposes. (This is a real example.) Motor was torn down and re-built after every mission. Company ordered a monitoring system to report motor speed, in order to avoid expensive maintenance procedure when possible. System reported when average speed dropped below so many RPM. Due to averaging process, a few hundred dropped IRQ's introduced only a small error, which was quickly absorbed into the statistics. If result was borderline, management could order tear-down and rebuild anyway, just on general principles. (Side note: the motor monitoring system had limited multi-tasking with tunable priorities, and ran on an original IBM PC XT. I learned a lot of vocabulary studying that code.) How well does that mesh with your understanding, dino? |
| dinotrac Jun 22, 2009 6:14 PM EDT |
gus3 - That's a pretty fuzzy way to look at it. You can have a hard real-time system without catastrophic (depending on your definition) results. Telephone switches come to mind. You might miss a connection -- which is certainly catastrophic to your call attempt -- but you can try again. Look again at what you wrote and realize how it maps to OS requirements: If it is catastrophic for an event not to complete in time , then you have to guarantee some non-catastrophic handling of the event within your time constraint. The only way to do that is to terminate processes that will not complete in time and provide some alternate "safe" default handling. Otherwise, you are at the mercy of the application and any bugs therein. |
| gus3 Jun 22, 2009 7:05 PM EDT |
Gah... addressed to the wrong person. Will correct. |
| gus3 Jun 22, 2009 7:19 PM EDT |
As I understand it ("program failure"), your telephone switch example does qualify as "hard real time." The attempt has failed catastrophically, and cannot be recovered. Even though we're using different definitions, I think our understandings probably line up. EDIT: I say "program," you say "process." Yours is more correct. |
| dinotrac Jun 23, 2009 3:34 PM EDT |
gus3 - Yes. The telephone switch example absolutely is hard real time. In fact, I spent a xome time at Lucent, which is where I finally learned the meaning of real-time. |
| jdixon Jun 23, 2009 4:18 PM EDT |
> Even though we're using different definitions, I think our understandings probably line up. I'd say so, yes. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!