Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Being a DJ with RISC OS

By Jon Wright. Published: 22nd Nov 2003, 16:23:07 | Permalink | Printable

The people want entertaining. Jon Wright has the solution

Every user claims RISC OS is stable and reliable, but have you put its stability to the test? Could you trust RISC OS to entertain a room of friends looking for a party? Jon Wright did and here's how he pulled it off.

Like most people, I enjoy listening to music for pleasure whether it be at home or on an evening out. As well as listening, I also enjoy playing music to a party crowd - it gives you a real sense of achievement when people bust some funky moves to a song which you have just slapped on the decks.

I have been a DJ at a few friend's parties. They love it, I love it, it tends to be quite successful. You might call me an EJ rather than a DJ because I use a computer to produce uplifting beats rather than the traditional black frisbees or beer coasters. In the past, I have used Windows 98 and some mixing software to play mp3s to the crowd but this has left me in embarrassing situations when the software crashed and the sound output dies. There's nothing worse than this, it's like standing up in front of hundreds of people and forgetting what you were going to say.

I was asked to DJ for couple of friends' 21st birthday party. I agreed to do this and made a note to myself that I was going to use a totally RISC OS based solution which would hopefully spare me the anguish of a silent room and violent jeering.

I knew that the only option was to use AMPlayer and some sort of audio-wizardry front end but I also wanted something extra, I wanted to be able to crossfade between two tracks using a hardware mechanism rather than using the mouse to control the sound output. The reason for this is that it can be quite a challenge grabbing for a mouse when you're in the middle of a chaotic pub or club.

I discovered that a 200MHz StrongARM RiscPC has enough processing power to decode and play two 256Kbit streams at once. Generally, the higher the bitrate of an mp3, the more processing power it takes to decode it and most of my MP3s are 256kbit. AMPlayer, the popular MP3 player module for RISC OS, also supports multiple instances using the SharedSound module. This means the user can play more than one MP3 at once.

Using Desktop Acorn C/C++ and the Toolbox, I knocked up a simple application that enabled me to crossfade between two SharedSound clients. My intention was to hook my application to two instances of AMPlayer which would each be using one SharedSound client. First setback! I discovered that the AMPlayer module created a new SharedSound client for each play of a song meaning that I was losing the SharedSound handle that my Toolbox application required in order to adjust its volume.

I was kindly allowed by the maintainers of the AMPlayer source to have access to the source code so that I could modify it for my own purposes. I changed is operation so that when a new AMPlayer instance is created, it creates a SharedSound client that exists for the lifetime of that instance. Doing this meant that I was now able to crossfade successfully between two playing tracks.

At this point, I was able to consider building some sort of hardware interface to allow me to control the crossfading using a sliding potentiometer as seen on normal mixing desks. I dug out my AKA10 user/analogue port podule that I've had lying around for years and looked towards fitting it to my RiscPC. Some of you may know that doing this requires some judicious work with a hacksaw - something which I admit I was a little worried about doing initially. About an hour later and I discovered that you can only fit this podule in the 2nd slice of a RiscPC unless you have a StrongARM card which has been mounted at a 90degree angle.

I appeared to have lost the user manual for my AKA10 so with the help of Richard Murray's StrongHelp manual, I was able to correctly wire up a 10K linear potentiometer (a sliding volume control) to the analogue port of the AKA10 podule. I booted the RiscPC and tried, as a simple exercise, to read the analogue port in BASIC. Disappointment! The board refused to give me a reading. With a great deal of further help from AMPlayer developer Thomas Olsson, we were able to discover that the IRQ jumper needs to be set for the analogue port on the podule before you get any readings.

With some adjustment to my Toolbox application, I was able to control my GUI crossfader using my rather bare looking potentiometer. With the help of Thomas, I fine-tuned the cross fader so that the overall volume level doesn't appear to change as you fade between two tracks.

With the ability to play two songs at once and crossfade them out of the way, I concentrated on a way to search through a large number of mp3s to satisfy any requests that may come in on the night. Stephen Fryatt's Locate appeared to fit the bill although it did have issues searching for files within ridiculously long directory pathnames. Steve is aware of this problem and also made the point that the Filer gets unhappy with pathnames over 210 characters and that RISC OS can only reliably support around 230 characters, when passing messages to and from applications. Like any other well meaning RISC OS software developer, Steve responded quickly to my queries and has made a new version of !Locate available that at least does some error checking on these longer pathnames.

No further software was required but seeing as I was going to use this DJ exercise as a vehicle for proving RISC OS, I installed RISC OS Select onto the RiscPC. A large (well, it used to be large) 40GB hard disc was to be the stable for the large selection of mp3s and 32MB or RAM was deemed to be more than enough for this exercise.

With the computer side of things sorted, I also had to find some large speakers which a friend of mine was able to loan to me along with amplifier kit that was powerful enough to drive them.

The final moment
The night arrives and I've got a car loaded with equipment which I have to set up on a pool table. In true ram raider style, I drove up to the front door of the pub and collared a load of people to help me carry stuff in. As well as the RiscPC and the sound system, I also had an old laptop PC as a backup system should (heaven forbid) RISC OS or any of the apps running on it crash.

I quickly discovered that my sound system was not enough to fill a very crowded pub but I was fortunately able to hook my unamplified line out to the pub's sound system which has about ten speakers connected to it.

Throughout the night, RISC OS sat there seamlessly doing its job. Nothing broke, it just let me get on and do it. My homemade hardware worked a treat. It may have looked quite ridiculous but it did the job. I was showered with compliments at the end of the evening although I suspect that may have been to do with the selection of music rather than the fact I was using RISC OS.

Next time I do a gig, I want to do proper beat mixing. This will require usage of two sound output devices - something which would be made easier if SharedSound had some concept of more than one output device. Failing that, perhaps using an Iyonix and Aemulor's surround sound card driver will be the solution; front outputs could be one channel and the rear outputs could be another allowing the Iyonix and RISC OS to act as a two channel mixer.

For me, RISC OS is can do. Just do it? I just did it.


See description below
Jon with his RiscPC and DJ rig

See description below
Radio 1, watch out

See description below
Screenshot of Jon's mixing software


Amplayer website

Previous: CJE Paints The Town
Next: Custom Cases, The Third


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

I run a school bar - If you can turn this into a tough, semi-commercial product usable by youngsters (18 year olds) I'd be very interested.

 is a RISC OS Usermartin on 22/11/03 5:26PM
[ Reply | Permalink | Report ]

The last time I saw someone DJing they were using a PC and every so often they had to do a quick (well slow :-)) re-boot. I presume to prevent crashes. I agree with the previous comment that this could be an idea for a commercial product.

 is a RISC OS UserMart on 22/11/03 8:11PM
[ Reply | Permalink | Report ]

This would be an excellent commercial product. A searchable MP3 database like the one in MusicMatch Jukebox would come in handy for requests.

 is a RISC OS Usertimephoenix on 22/11/03 9:56PM
[ Reply | Permalink | Report ]

Interesting, but is it legal?

 is a RISC OS Userimj on 22/11/03 10:06PM
[ Reply | Permalink | Report ]

Bloody fantastic effort! A killer product?

 is a RISC OS Userpipalya on 22/11/03 10:17PM
[ Reply | Permalink | Report ]

imj: Why would it not be legal ?

 is a RISC OS UserGrek1 on 22/11/03 11:27PM
[ Reply | Permalink | Report ]

Nice one, ix.

I had considered a project but not being able to sync the bpm of different tracks did seem like a real limitation. It's be nice to see if this was possible on a RiscPC with 128kb mp3s.

-- Spriteman

 is a RISC OS UserSpriteman on 23/11/03 12:51AM
[ Reply | Permalink | Report ]

This looks great! What would make it better is if you could search IDv3 tags for artist, album, year of release or even track number on an album. That way punters can be more vague about their requests. "Err, it's the 3rd track on Club Remix 2001. You know what one I mean?" Great idea, and a great implemntation too.

 is a RISC OS UserSmiler on 23/11/03 6:47AM
[ Reply | Permalink | Report ]

Spriteman> syncing the BPM of different tracks would require the ability to monitor your 2nd track independently from the playing track. One way this is possible is by using a 2nd output device (eg. Irlam 24i16 card). Additionally, pitch control (ie. adjusting the speed of playing tracks) is required. This is not something that is directly provided by AMPlayer but I would envisage using the AMPlayer module to turn MP3 streams into raw samples and then using a separate player to allow controlling of pitch.

Smiler> that would be useful although this does of course mean that all the information has been entered correctly :)

 is a RISC OS Userjonix on 23/11/03 12:39PM
[ Reply | Permalink | Report ]

Spriteman> incidentally, a StrongARM RiscPC could cope with playing twp 256Kbit streams at once from the tests that I performed. This does result in a rather sluggish desktop though.

 is a RISC OS Userjonix on 23/11/03 12:47PM
[ Reply | Permalink | Report ]

Would an app like Wimp 2 enable even more performance?

This would be a marketable product, especially if used on the iyonix with one of those cool cases ;)

Perhapss another app to pre-read files and calculate their BPM? then use an addon to AMPlay to adjust the new track accordingly?

Also the use of a second screen for advanced visualisations for flashy lights is another great idea

hope this can work you for you! :)

 is a RISC OS Userem2ac on 23/11/03 1:49PM
[ Reply | Permalink | Report ]

Sharedsound could "fool" amplayer into playing tunes faster/slower by passing in a slightly different multiplier (usually used to correct for different sample rates) AFAIK the source code for SS isn't available but as with everything, it's not hard to hack. You could then write a program call a sharedsound SWI to tell it a multiplier depending on where your lever is (or whatever).

Wimp2 wouldn't enable more performance, PMT doesn't make the CPU faster, it just doles it out differently. AMPlayer runs on callbacks so it can grab cpu time when foreground apps are running. Once I heard mention that they were looking at making amplayer decode during disc reads, but it sounds hard to me.

I've often wondered why Sharedsound wasn't designed to handle multiple independednt outputs, but then again it isn't a problem for most people. I expect someone with a little thought about APIs and such could come up with a multi-output SS type module.

 is a RISC OS Userjohn on 23/11/03 2:12PM
[ Reply | Permalink | Report ]

Wimp2 wouldn't necessarily help. The desktop is sluggish simply because of the processing power required to decode the mp3 streams. I would be interested to see how the Iyonix would cope (I imagine much better).

I have not yet seen an algorithm which will calculate the BPM of a track accurately. I would be interested to hear if someone knows of one.

True DJs will prefer to match records themselves by adjusting pitch rather than using pre-calculated BPM counts because this can take the fun away from actually playing the music.

Advanced visualisations and light control would certainly top such a project off but the former would certainly require plenty of CPU power depending on what effects you're after.

Using mp3s as a storage mechanism is not ideal, you can't guarantee you won't come across corrupted frames and that the frames will all be the same length. This means that calculating an offset in an audio file is not accurate.

Considering the price of large hard discs and the fact that many DJs will have a "record bag", it may be better to use raw sound sample data which, although requires more initial bandwidth to retrieve from disc, will require significantly less CPU power allowing time for DSP or visualisation effects.

 is a RISC OS Userjonix on 23/11/03 2:22PM
[ Reply | Permalink | Report ]

John> A multi-output SharedSound module would be the best case. Preferably thought for how the API may interact with sound hardware drivers on the Iyonix (which may include surround sound, Dolby, etc) should be taken into consideration.

 is a RISC OS Userjonix on 23/11/03 2:25PM
[ Reply | Permalink | Report ]

I thought that the ATI range had the ability to do visulisations from a raw sound passed to it? i know mine can. (using the Viewfinder)

although Wimp 2 wont make the process faster, i just thoguht that you could give the desktop more time slice to speed the redraw up a little?

having used my PC as a DJ machine, I know that the re-start thing is THE WORST THING THAT CAN HAPPEN - big silences (our big problem was the SB Live card packing up due to too much data being passed to it?)

if the schematics of the connections and the software were availible, i know my Risc PC would be travelling in my car ;)

What ever happens, good luck!

 is a RISC OS Userem2ac on 23/11/03 2:34PM
[ Reply | Permalink | Report ]

How well does it crossfade tracks by Mr Walkie Talkie?

 is a RISC OS Userpiemmm on 23/11/03 3:47PM
[ Reply | Permalink | Report ]

I don't get this crossfading thing, one tune ends, everyone claps, the next one starts

 is a RISC OS Usermavhc on 23/11/03 3:50PM
[ Reply | Permalink | Report ]

As far as I can see, the best way to change the bpm for the audio is to attack the raw audio streams. You can do some funky manipulation in software. For instance, Window Media Player can change the playback speed without altering the pitch. Combining the two effects would allow you to play back Beyonce a little faster without making her sound like a chipmunk :)

-- Spriteman

 is a RISC OS UserSpriteman on 23/11/03 6:36PM
[ Reply | Permalink | Report ]

Spriteman> On a turntable, you probably only have the ability to change the pitch by +-10% which may only begin to start Beyonce sounding like a chipmunk :) I believe the technique that you are referring to is called time stretching.

 is a RISC OS Userjonix on 23/11/03 6:50PM
[ Reply | Permalink | Report ]

e2mac: to increase the desktop timeslivce you would have to take some away from AMPlayer, which would mean that you'd have gaps in your sound. I'm presuming the sound being continuous is pretty much essential for the system. Spriteman: the best way to change bpm is surely just to play it faster. No-one really notices that kind of thing :) Although admittedly I don't know how time stretching works, presumably some sort of frequency analysis and regeneration.

 is a RISC OS Userjohn on 23/11/03 8:38PM
[ Reply | Permalink | Report ]

10% on Crazy In Love is enough to do it :)

The process that I mentioned could be called time-stretching but it doesn't incur the strange distortion that was associated with earlier versions of this process. ISTR that there was an app for RISC OS that could process sound samples to produce the stylised and distorted time stretch.

-- Spriteman

 is a RISC OS UserSpriteman on 23/11/03 8:39PM
[ Reply | Permalink | Report ]

Yes, it was on one of the Datafile PDCDs (either 3 or 4) so it's probably kicking around somewhere on the web. If I was at home now I could look up its name...

 is a RISC OS Userhutchies on 24/11/03 12:53PM
[ Reply | Permalink | Report ]

Timestretch is what I was on about.


-- Spriteman

 is a RISC OS UserSpriteman on 24/11/03 2:29PM
[ Reply | Permalink | Report ]

martin: "I run a school bar"

Things have certainly changed since I was at school...

mavhc: "I don't get this crossfading thing, one tune ends, everyone claps, the next one starts"

You've been missing out, although if the music "on the decks" is vanilla Kylie Minogue, then you haven't been missing out by much. ;-)

 is a RISC OS Userguestx on 24/11/03 4:13PM
[ Reply | Permalink | Report ]

My brother-in-law did some cool DJ stuff at a wedding once - it involved using a Linux box and a custom-written visualisation plugin for XMMS that would drive a laser show thing to the beat of MP3's stored on a CD.

It was pretty good, with different pcitures being drawn and also a motor to control the disco ball RPMs!

This was all done on an old P166 laptop as the PII-300 that was supposed to do it couldn't boot to Linux as a Windows virus had nuked the boot sector! ;)

There was no fading or any of that stuff, but it was very impressive that the Pentium did so well - I guess it has the FPU that the StrongARM lacks....

 is a RISC OS Usersimo on 24/11/03 5:38PM
[ Reply | Permalink | Report ]

I would be interested in trying this? any idea if we would be able to see such a program for download?

 is a RISC OS Userem2ac on 24/11/03 5:48PM
[ Reply | Permalink | Report ]

That's totally cool. ;)

 is a RISC OS Userharmsy on 24/11/03 5:58PM
[ Reply | Permalink | Report ]

Some food for thought :

- The iyonix could easily perform twin MP3 decoding plus some pitch/time shifting to match BPMs, and maybe even some visual - Using a PCI soundcard, you could output mutiple audio streams, or even perform some of the frequency/time shifting using an onboard DSP.



 is a RISC OS Userspellinn on 24/11/03 6:30PM
[ Reply | Permalink | Report ]

OK banned-word-typo should obviously be "shifting" ;-)


 is a RISC OS Userspellinn on 24/11/03 6:32PM
[ Reply | Permalink | Report ]

s-h-i-f-t-i-n-g !!! grrrr....

 is a RISC OS Userspellinn on 24/11/03 6:34PM
[ Reply | Permalink | Report ]

mmm very tasty neil ;-)

The simplest way to do this Iyonix style would be to use a 5.1 card to get two audio streams out into a standard 2 channel mixer and then out to the sound rig.

The iyonix would then just be acting as a multi channel source with speed control.

Could we persuade you to have visions of product ideas at this juncture Mr. Spellings?

Before you go and buy Risc OS ltd of course.... ;-)

 is a RISC OS Userepistaxsis@work on 24/11/03 7:59PM
[ Reply | Permalink | Report ]

I know this is about DJing but if anyone has seen: [link]

Maybe someone should try and market a product like this?

 is a RISC OS Userninjadonkey on 24/11/03 11:43PM
[ Reply | Permalink | Report ]

Keith> Yes, I made reference to Aemulor's surround sound card project in my 2nd last paragraph. It would certainly be a good way to go forwards but I believe we need an OS standard in terms of sound output devices so that we don't end up with several audio cards each featuring a different mechanism for driving them. SharedSound goes some way to addressing this in terms of providing a unified way of driving the sound system but the future needs to be considered and something designed appropriately.

 is a RISC OS Userjonix on 25/11/03 11:55AM
[ Reply | Permalink | Report ]

Ah!!!! at last the word UNIFICATION!

I see hope for the platform yet...

 is a RISC OS Userem2ac on 25/11/03 12:58AM
[ Reply | Permalink | Report ]

We agree with having some kind of standard allowing for future expansion, other 3rd party sound cards etc without creating the situation we now have with the two different USB stacks for example.

The problem is developing an "open" API often takes as long as writing the driver in the first place, and customers are waiting.. :)



 is a RISC OS Userspellinn on 25/11/03 5:31PM
[ Reply | Permalink | Report ]

Yes I appreciate that customers are waiting so make sure any work you do is abstract enough to enable it to plug into an open sound API that should be discussed with the programming community. That way you can satisfy the immediate demand of requiring something which you can sell and also avoid some kind of sound API split.

 is a RISC OS Userjonix on 25/11/03 10:42PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Archive booklets review part one
    MessengerPro, VirtualRPC, simple networking and programming guides
     20 comments, latest by jlavallin on 19/12/05 3:28PM. Published: 12 Dec 2005

  • Random article

  • expLAN provide online anti-surge help: With all the recent storms an'all..

     Discuss this. Published: 1 Nov 2000

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "You are just users, irresponsible and overly sarcastic"
    Page generated in 0.2227 seconds.