Slashdot Mirror

Of course, alsaplayer won't be able to play the iTunes files, but maybe the iTunes player can be modified to also do this.

are there any linux MP3 players that let you adjust speed and pitch?

The upcoming version of AlsaPlayer will support FLAC streaming over HTTP, and even seeking if you use HTTP 1.1. We should see FLAC streaming support in Icecast soon, at least I hope so.

-adnans (*plug*!)

<plug>

Consider using AlsaPlayer as the backend for your project. AlsaPlayer supports so called interface plugins, where you can write your own custom front-end to the player if your needs are that specific. The current CVS version supports a "daemon" interface where the player will just run as a background process and accept commands through the libalsaplayer control interface. There are already a couple of projects preparing to switch to this interface. I know of at least one commercial project that is currently programming a backend.

</plug>

-adnans

• Quake ready!
• Jukebox interface
  
  and
  
  
• PVR / DivX playback support

• Quake ready!
• Jukebox interface
  
  and
  
  
• PVR / DivX playback support

• Quake ready!
• Jukebox interface
  
  and
  
  
• PVR / DivX playback support

FinalScratch runs on Linux now, since BeOS is pretty much dead. At least that's what I heard.

You can simulate a cheap Finalscratch by using AlsaPlayer and feeding the speed parameter via an external program, using libalsaplayer. Some folks are already doing this in a lab. There's this rumour that FinalScratch is using some bits of AlsaPlayer (plugins), have to check if this is really true ;)

-adnans

If you feel adventurous you can try and duplicate what this guy is doing:

http://www.cs.ubc.ca/~tbeamish/digitalturntable.ht ml

They are using AlsaPlayer (shameless plug :) for doing sound output and scratching. I'm currently working on a software only scratchin system, much like TerminatorX.

Incidentally, I just heard a rumour that FinalScratch is indeed using some parts of AlsaPlayer, the plugin system. Wonder if that's true.

-adnans

ALSA = lowlevel soundcard drivers
JACK = highlevel audio (PCM) API

So JACK is using ALSA to output audio. The nice thing about JACK is that it's the first serious attempt in the Linux (Unix) world to get a professional audio API in the hands of developers. SGI's dmSDK was promising but that project seem to have stalled, i.e. no open development going on (no CVS). JACK also replaces arts and esd when it comes to multiplexing audio output. The only problem is that developers may find they have to redesign their whole audio application in order to fit inside the JACK (callback based) framework.

A typical Linux/Unix audio application opens a special file and starts writing the audio data to it. The application will block on the write() (or read() when recording). This works fine for simple things like playing an mp3 or doing some window manager sound. It gets hairy when you try to sync multiple audio applications and achieve low latency at the same time. With jack this is as easy as pie, because the applications are driven by the JACK callback. So when it is time for the soundcard to get its next buffer JACK simple calls the process() function of all the connected audio applications. Every application has the chance to insert its own piece of audio data (or inspect what's already there), all app will always write the exact same amount of samples per callback, which keeps them in perfect sync. You can also do cool things like create your own ports and wire JACK aware apps together. In short, it rocks :-) ..and it makes Linux a worthy competitor to OS X's CoreAudio.

More on this at the JACK website

Shameless plug :-) AlsaPlayer was the first released JACK app, mainly because of its BeOS heritage (the internals work exactly like the ancient BeOS audio_server, which was callback based).

-adnans

I already have, in my previous post.

Oh, I remember refuting many (all) of your points against Linux/X11 a couple of weeks/months ago. I will pick legacy, network transparant, X11, with Geforce2, full OpenGL, over BeOS Vesa 2.0 any day, thank you very much. It makes practical and technical sense...

The next part of your arguement basically boils down to "ignore all the technical reasons, Be died so BeOS must have sucked," and "BeOS sucked because it wasn't easy to port to."

If you want to read it that way, sure. I never said BeOS sucked, however it's faaar from being superior. I was into Be probably way before you even heard of them. I have a BeBox to prove it :) I spent countless hours coding neat stuff for BeOS (it wasn't even called BeOS back then). Hell, I ported one of the first MP3 players over to BeOS :-) I know all about its pervasively multithreading enviroment. Back then I was simply amazed at how easy it was to get graphics and sound mixed with threads. But it was always a toy. You could do neat stuff with it, but there were no real advantages over other OSes at the end of the day (with the exception of the journalled FS).

GTK+ 1.2 is hardly thread safe. According to the GTK+ FAQ, there is a global lock on the whole system which negates any advantages of threading

Oh really? I think you need to take some more classes on threading then. Since your videocard is not multi-threaded all drawing events gets serialized at some point. The global GTK+ is ugly, but very effective. And your applications still take advantage of threading, if you code them correctly. Heh, just a couple of days ago I hit a locking bug in my pet project. The whole GUI froze because I acquired a lock twice, yet the music kept playing on. It even jumped to the next song in the playlist. The GUI thread was deadlocked, yet my audio and disk thread continued like there was nothing wrong. Sure, gtk+ global locks negates any advantage of threading, NOT! You use threads to do CPU intensive work while still being able to process other events (like the GUI). You do not use threads to fight for the single 2D pipeline that most PC graphics cards have these days.

As for Qt 3.0, it hasn't been released yet, so it is of no consequence at the moment.

Oh dear, I should wipe my stolen copy quickly then!

The reason I say that GUI developers should be forced to use threads is because, all too often, developers try to use (comfortable) procedural techniques to do GUI programs, which ineherently lend themselves well to a messaging/multi-threading model.

With the risk of not taking into account the technical advantages this has I will say that this model hasn't helped BeOS one bit! The fact that any programmer that wanted to put a BWindow on the screen had to deal with threads and locking has IMHO stiffled application development a great deal. Just look at BeBits.. it's full of "Hello World" style apps. There are very few mature applications available.

Anyway, JBQ makes a good point: it is hard to port non-threaded software to a threaded environment

He also points out that there are fundamental problems with the way BeOS handles inter-thread messaging. These problems will probably not bite the average graphics viewer coder, or the mp3 player program, but they will bite once you start coding moderately complex tools.

Threads are cool, I use them every day. But like you say, they are not the silver bullet. On a sidenote, my heavily multithreaded audio player has been churning through a 3000 entries long playlist for 2 straight days now, rock solid :) Oh, and it uses GTK+ for threading the scope windows. Yes, each scope window has it's own worker thread, just like BeOS. In this case, it is usefull to have multiple threads calculate and draw the scopes in offscreen bitmaps before blitting them to the screen. Bottom line: use threads where they're usefull, don't use them pervasively (perversely :), just because it's technically "cool".

BTW, you should go back to the forum/discussion area I pointed out earlier. There's some more interesting notes from JBQ on the "pervasively multithreading" nature of BeOS (He mentions smoke and mirrors.... ugh :)

-adnans

• Konqueror TV. Finally browsing on a TV becomes viable. At 800x600 text is very reasonable and the screen is big enough for most webpages.
• Quake III. This really rocks!! If Loki keeps pumping out games there won't be need for a separate console, at least not in my house.
  
  

• Konqueror TV. Finally browsing on a TV becomes viable. At 800x600 text is very reasonable and the screen is big enough for most webpages.
• Quake III. This really rocks!! If Loki keeps pumping out games there won't be need for a separate console, at least not in my house.
  
  

You don't need a PS2 in order to do that. Get a Geforce2 MX400 and the latest NVidia drivers. Hook the s-video port up to your TV (PAL or NTSC) and enjoy! I have successfully played Quake 3 on my TV, excellent picture quality and very fast too! Here's proof. And here is Konqueror displaying /. This card will even display the console at bootup if you only have your TV hooked up, unlike the Matrox cards.

-adnans

You don't need a PS2 in order to do that. Get a Geforce2 MX400 and the latest NVidia drivers. Hook the s-video port up to your TV (PAL or NTSC) and enjoy! I have successfully played Quake 3 on my TV, excellent picture quality and very fast too! Here's proof. And here is Konqueror displaying /. This card will even display the console at bootup if you only have your TV hooked up, unlike the Matrox cards.

-adnans

• Sony PAL TV with s-video and dual SCART input (G4xx supports both PAL and NTSC output)
• AMD Athlon 700
• Matrox G400 MAX (any G4xx dualhead will do)
• Hollywood+ / DXR3 MPEG decoder card
• Trident 4DWave NX
• Wireless SK7100 keyboard (full Linux support using 'hotkeys')
• Logitech wireless mouse (PS/2)

• Linux 2.4.0-XFS (80Gig *bloody fast*, journalled XFS data partition)
• Debian Woody (the best :)
• XFree 4.0.2 + Matrox mga.o binary with HAL
• WMaker 0.60.4, for proper Xinerama support
• aviplay + plaympeg for fullscreeen DivX ;-) / MPEG2 playback
• AlsaPlayer for music *grin*
• ROX for cool desktop icons and File browsing
• Anything else that runs OK at 640x480 or 800x600

• Sony PAL TV with s-video and dual SCART input (G4xx supports both PAL and NTSC output)
• AMD Athlon 700
• Matrox G400 MAX (any G4xx dualhead will do)
• Hollywood+ / DXR3 MPEG decoder card
• Trident 4DWave NX
• Wireless SK7100 keyboard (full Linux support using 'hotkeys')
• Logitech wireless mouse (PS/2)

• Linux 2.4.0-XFS (80Gig *bloody fast*, journalled XFS data partition)
• Debian Woody (the best :)
• XFree 4.0.2 + Matrox mga.o binary with HAL
• WMaker 0.60.4, for proper Xinerama support
• aviplay + plaympeg for fullscreeen DivX ;-) / MPEG2 playback
• AlsaPlayer for music *grin*
• ROX for cool desktop icons and File browsing
• Anything else that runs OK at 640x480 or 800x600

• Sony PAL TV with s-video and dual SCART input (G4xx supports both PAL and NTSC output)
• AMD Athlon 700
• Matrox G400 MAX (any G4xx dualhead will do)
• Hollywood+ / DXR3 MPEG decoder card
• Trident 4DWave NX
• Wireless SK7100 keyboard (full Linux support using 'hotkeys')
• Logitech wireless mouse (PS/2)

• Linux 2.4.0-XFS (80Gig *bloody fast*, journalled XFS data partition)
• Debian Woody (the best :)
• XFree 4.0.2 + Matrox mga.o binary with HAL
• WMaker 0.60.4, for proper Xinerama support
• aviplay + plaympeg for fullscreeen DivX ;-) / MPEG2 playback
• AlsaPlayer for music *grin*
• ROX for cool desktop icons and File browsing
• Anything else that runs OK at 640x480 or 800x600

• Sony PAL TV with s-video and dual SCART input (G4xx supports both PAL and NTSC output)
• AMD Athlon 700
• Matrox G400 MAX (any G4xx dualhead will do)
• Hollywood+ / DXR3 MPEG decoder card
• Trident 4DWave NX
• Wireless SK7100 keyboard (full Linux support using 'hotkeys')
• Logitech wireless mouse (PS/2)

• Linux 2.4.0-XFS (80Gig *bloody fast*, journalled XFS data partition)
• Debian Woody (the best :)
• XFree 4.0.2 + Matrox mga.o binary with HAL
• WMaker 0.60.4, for proper Xinerama support
• aviplay + plaympeg for fullscreeen DivX ;-) / MPEG2 playback
• AlsaPlayer for music *grin*
• ROX for cool desktop icons and File browsing
• Anything else that runs OK at 640x480 or 800x600

So your big alsaplayer advantage is shot...

Really, I implemented this backward playing just to see if I could :) .. There's no advantage to it, it's just funny. Oh, and alsaplayer was the first GPL player to play stuff backwards, so there! :)

Oh yeah, on most Be systems soundplay can play about 30 mp3's backwards, forwards, and at different speeds... simultaneously, and without skipping.

How about 36 simultaneous songs *without* skipping backward/forward on my Trident NX using alsaplayer and ALSA on Linux? Of course this multiple simultaneous song playing is TOTALLY useless in real life, but hey, it's nice for articles right? I wish Be people (I was one once :) would venture a little outside their OS domain...BeOS is loosing its uniqueness every day (boy was it cool, back in 1996!)

-adnans