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."
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!