Slashdot Mirror
MP3 Player - The Be Way
shyster writes "Be has created a prototype mp3 player that puts all other hack jobs to shame. Using an Intel 810E chipset with a Celeron-400MHz processor, and relying on BeOS's wonderful file system (where attributes are stored with the files) for database search capabilities, this thing really makes BeOS look good, as well as emphasizes it's audio/video capabilities. They don't plan on making this thing themselves, but rather customizing and branding the OS for OEM partners to place in their own hardware solutions. This kind of approach should allow for some differences between devices, such as having a CD-RW, DVD drive, touchscreen LCD display, etc. The other great thing about this is that it's networked.
Check out the full story here."
Multimedia is only going to be more and more integral to everyday information appliances (not just stereo components and PVRs). What answer does Linux have to this with its mishmash of incompatible multimedia technologies?
To me, this article indicates exactly why operating systems like BeOS will continue to make inroads into the embedded market, while Linux is in serious danger of losing out. Be is designed and marketed as a "multimedia OS", and uses like this allow it to really shine. How long before the built-in features of BeOS are more than anyone doing it from scratch in Linux will want to compete against? Isn't it already that way?
My feeling is that the multimedia capabilities in BeOS will eventually obviate the need for Linux's primary strength in the embedded market--the availability of source code. If an OEM-ready platform already has support for all the stuff you'd want to hack into Linux, is small and cheap enough, why NOT use it? Isn't the whole reason TiVo used Linux so they could add in all the multimedia stuff they needed that Linux didn't provide? (And don't tell me they did it for philosophical reasons. OEMs want results, not dogma.)
If Linux wants to compete in this space, it needs focus, which seems to be the one thing it doesn't (yet) offer.
The only certainty is entropy.
Imagine a centralised MP3 server networked (both 802.3 and 802.11 - thats ethernet and wireless for the young ones) to other appliances around your house. Choose a MP3 track and listen to it from your Hi-Fi / TV / Refrigerator / PC / backyard hammock on a internet appliance etc. Listen to a streaming MP3 server, and immediately download more songs from the same group. Little Johny listens to kiddie MP3's from the bedroom, Mrs Jones listens to a hip song in the kitchen while Mr Johnes listens to a blues song in the garage - all songs are streamed from one box. Stick a new CD in, convert the audio to MP3 (with online lookups) and all networked devices in the house have access to the new songs. With MP3 storage space reaching double gig digit storage sizes (>10G) it becomes more and more cumbersom to issue searches, as well as a problem of duplicating data. I think that this custom built MP3 box on steroids provides so much more than anything I can muster myself. This appliance will be idiot proof to operate, and you'll be able to buy it at your local electronics shop. Nice.
Revolution = Evolution
The difference here is: the BFS doesn't index its files centrally to some index. Each file has a variable amount of attribute data that can be extended as the user/developer wishes. That attribute information is stored directly in the file system info tree, although if it gets really big its stuck into a hidden file [or extra node/block actually].
This is super-slick because the file system info tree is structured mostly in places where the head of the drive can get to fast, and usually right next to tons of similar information about all the files in a directory or group of directories. This way you can read a couple blocks of file attribute information without ever having to actually skip to the files themselves and search that, thus acheiving a great savings in head movement. Its similar in basic concept to the BSD Fast File System and the Linux Ext2fs, in that they do the same for filenames, sizes, and other attributes. But the BFS has extensible attributes.
So extensible attributes mean: I downloaded a file from somewhere, besides just a filename=foo.tgz, I could put a from_URL=ftp://ftp.foo.org/pub/foo/src/tgz/ attribute there. All mail messages have their subject, from, to, reply to, and all that stuff stored as attributes, and all mp3s have their ID3 tags (and possibly more) stored as attributes. So you can just grab stuff that matches the attributes you want. This happens really quickly because the head only has to skip to the general inode information, better yet, any smart OS will cache all that in memory, so a large portion of your search is done without drive head movement.
Large attributes exist too. For example some drawing programs store a scaled down preview in an attribute... fair enough, that is in an extended attribute node/block, but that node/block doesn't have to be searched or then cached unless it's known to contain the key that is being searched for.
So sure, any OS could go ahead and index mp3 id information, cache it, maintain coherancy between it and the fs, and search through it, but for Mac OS, that would take a seperate indexing phase, an extension that pays attention to fs changes and updates the index, and a special extension to a special searcher (the BFS search is just an fs feature with a gui interface) that looks through the special index. And that is just as feature rich, but it lacks the performance considerations that were taken into account when building such things directly into the fs.
I do like the Mac, unfortunately Be sucks for not keeping developers more PPC aware, even if Apple forced them out of developing for G3 [not that that has stopped NetBSD or linux even]. It's a real shame because the BeBox was one of the coolest ideas in a long time, especially because of the OS, but not solely... the PPC is a cool chip (literally too).
-Daniel
P.S. The guy who developed BFS presented it as a talk at WPI (cause he graduated from there), and the guy who developed Ext2 came to talk to the linux group a few weeks earlier over how it worked and what may be done differently for Ext3. Both were very informative
Journaling, Schmournaling. Be's filesystem keeps information about files in a metadata database. You can add arbitrary information types to this metadata, and you can search the filesystem for files.
For instance, you can add Artist, title, album, live/recorded, and bitrate to the information on the file. Then you could search for all live recordings by Tori Amos or Limp Bizkit, at a datarate above 128 kbps, sorted by title.
All without writing but one line of code (the search query)
-
Just because it works, doesn't mean it isn't broken.
Hello,
/. Aura is nothing more than networked mp3. Lot of people have done it. And also as mentioned above this has nothing to do with the journaling filesystem (which just happens to be the default fs on Be). When articles like this are posted people are incited to point out the holes in the article and thus create FUD towards Be. I understand Be is not a free OS. But we here in France have a strong Be following and are faithful Be users. I would really like right information on Be posted here, instead of FUD and things that anyone could point fingers at. Sorry for my bad english.
As a Be user, I find it frustrating when I see things twisted around and posted as news on sites like
Hi,
I tried Aura a few weeks ago on BeIA developer forum. But I must say that it's nothing as mentioned here. I mean the mp3 player bit is just a normal mp3 player. It's got networking (sort of like the way most people host mp3's on nfs mounted partitions). The default filesystem (Be Journaled fs) just takes care of all directory work. This could be easily implemented in almost anything else. Also it has nothing to do with Be's mp3 player.
I saw one such implementation with a LDAP and NFS. A script goes and constructs LDAP entities for all songs. It's tiresome if you dont have the stuff in the mp3's to begin with. But the LDAP imeplementation is magnitutdes faster. I dont know why the author of the article missed this altogether. And maybe some reaserch before posting the article on slashdot might have stopped all the trolls here today!
Enjoy
Beed!