JM Geremia wrote:
> I couldn't agree with you more. It is "nifty" to have audio cds mounted
> as .aiff files. That's the whole reason that I wrote audiofs about a year
> ago. My filesystem allowed you to mount cd tracks as either .au or .wav
> files and could be compiled as a kernel module. Personally, I think the
> conversion to .aiff is a little bit much, especially if there is any
> compression going on. Why compress the cd output stream? There's
> certainly enough room for it on the raw media.
--- .aiff was uncompressed, .aifc was compressed -- at least by my understanding.> Still, I'd make the move to PCs in a heartbeat. --- Hopefully as we continue to expand our Intel offerings you might find some of them to your liking...:-)
> > However, there are one or two points about IRIX that I don't like: > > 1) CPU usage is unacceptably high > > 2) CD command response time is slow > > 3) Anything else that accesses the audio channels stop the CD > from playing, even during a virtual file read. > > 4) A process reading a cd file that zombies leaves the > CD rom in an inaccessable state > > You would probably know better than I would, but I feel these are all > artifacts of the fact that the OS is doing _way_ too much here. --- I think it is an artifact of using old hardware and old hardware compatible algorithms. The way I understand it (I am not an audio CD expert nor have I looked at that code), but when accessing a data CD, you could get >1x read speeds. A limiting factor of audio CD's, was that they could only ever be read at 1X speeds. My belief was that this was because they weren't 'ripping', but sampling. Almost all of the desktop units in the past 4-5 years have had high quality AtoD circuits/DSP's. When that code was written 5 years ago you really only had 1X CD's -- so they they might have not been ripped digitally but using the (often) studio quality digital sound chips and algorithms. Depending on the machine, if the specialized hardware wasn't present, the CPU was automatically harnessed for the task. I'm guessing there was insufficient demand in our customer base for more/different algorithms.
I note that when ripping a CD to disk on a PC (audiograbber/audiocatalyst) it took a fair amount of CPU time with a 4-6X CD. As CD speed went up, so did cpu usage. With a slow CD and fast enough CPU, audiocatalyst could rip and compress at the same time, *barely* -- that was a 4X CD and 266MHz PII. Now CD's are up to 40X, but CPU speed is only 2-3x PII speed. So real time compression becomes a pain.
Another issue is *rt* priority. IRIX allows both 'rt' priority setting (by a root level process) as well as offering a 'w' (weightless) priority. 'w' is complete opposite of 'rt' in that it doesn't even count as 'load' in load calculation figures, isn't guaranteed to run, runs only in place of the 'idle' task. However that 'rt' setting is the one that can result in sluggish performance for other interactive tasks. If you are playing the CD at the same time, then you have 2 'rt' priority tasks that will have highest priority in the system. 'rt' doesn't share cpu space with interactive tasks or even kernel threads. If an 'rt' process runs amok -- you have to hit reset -- can't even remote login.
As for multi-program access -- seek times on CD's are *bad*. As soon as you do a seek you have to lose audio on a 1X CD since you can't be buffering ahead on a 1X CD. You also lose 'sync' since audio tracks have no 'sectors'. When you sought back to the original track, you'd have to do an average of a full spin to find the beginning of that 'cylinder' then read back up to the point where you left off. From what I understand, this is an unreliable science. So expecting multi-CD readers while maintaining audio-perfect ripping would be...?challenging? :-)
As for your point 4...well....hey, bugs are bugs. :-).
I'd expect if that a rewritten audio CD driver that uses modern hardware would improve on some of these issues, but a 40X CD is still delivering about 7Mb/sec of data that will need *rt* priority to be the most perfect. You would probably increase some of the slow access time you saw before, but not all.
> Thoughts? Suggestions? --- Did that answer anything? BTW, the above is strictly based on my own experience and opinion.
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:11 EST