22050 Hz audio on Pandaboard

Hi,

after years waiting for audio to be fixed on the Pandaboard, I’m asking for this as a wish.
This board is really great and powerful, but most *nix ports have audio problems in the form of “helium speak”, and so do most old Risc OS games.

22050 Hz could be resampled (like it is on Linux using ALSA’s dmix) to a supported frequency, in a transparent way.

Thanks

FWIW I’m currently experimenting with improved methods for integer-ratio ‘upsampling’ and DigitalRender. That may in due time help a bit. But too early to say at present. I agree it would be good to have a user-controllable way to resample like this. But it isn’t a trivial change.

Yes, I also think it would be good to something equivalent to the ALSA layer and the distinctions like those between hw: and plughw: which make things like resampling more flexible.

That said, my interest is mainly on being able to use the higher rates more effectively and with better results.

Jim

Steve and I started coding to resolve soundtrackers for Pi compatibility a few months back, we’ve been somewhat sidetracked getting VIDC1 to VIDC20 translation working, but its in progress.

From all the games we’ve had submitted to JASPP, the current count of games/tracker module are as follows:

MusicMod variants 39
QTM 12
Trackermod 11
Repmusic 7
DTT 5
SoundTracker 3

Steve started on MusicMod, it being the most common and the fact JASPP have the rights to release the games, unfortunately we noticed very quickly that most MusicMod modules with the same version no. are different, so we’re having to code various shims to translate them to QTM, which handles the frequency correction and 32bit support.

For games that aren’t using trackers, things get somewhat more complicated but possibly fixable by intercepting the relevant SWI’s etc and having the game write to a buffer, which is then upsampled to the host system frequency. I’m proposing to do something similar with the video output so we can up the bit depth from 4bpp and below to 8bpp min.

With the next release of ADFFS (it was finished last week, so imminently), we’ll be allowing public access to the JASPP developer forum where you’ll be able to follow and get involved in the development process, so keep an eye on The Icon Bar for the release.

For games that aren’t using trackers, things get somewhat more complicated but possibly fixable by intercepting the relevant SWI’s etc and having the game write to a buffer, which is then upsampled to the host system frequency.

For general RO uses it would be good if user-controllable resampling was provided in a module. From my POV the ideal would be for it to be included in either SharedSound or SoundDMA. At the moment we do have either linear interpolation or ‘FM’ . Neither of which is general enough, or indeed much good if the resampling isn’t a simple x2 rate ratio.

I don’t know the details for RO on the RPi. But on the ARMiniX and other machines *nix ports tend to use DigitalRenderer. That currently only goes to SoundDMA not SharedSound, which cramps resampling somewhat. If anyone is unfamiliar with this, some details are in

which I’ll be correcting and updating sometime. At present I’m experimenting with different resampling methods for general use and also testing a resampling audio player that output direct to DigitalRenderer to play out of the ARMiniX.

Jim

@Jon Abbott: I hope you can make your way and fix the tracker modules! That would be great and I understand it would fix the games for Pandaboard compatibility, too, right? (The Pandaboard playback rate lower limit is 44KHz, so I suppose you’re also including some kind of resampler in the new tracker modules so 22KHz modules can be played on the Pandaboard).

@jim lemsurf: If I understand you right, you could potentially fix Linux audio in Pandaboard ports, wich are plagued with hellium voices, as these ports seem to use DigitalRenderer, am I right?

jim lemsurf: [ who he? :-) ] If I understand you right, you could potentially fix Linux audio in Pandaboard ports, wich are plagued with hellium voices, as these ports seem to use DigitalRenderer, am I right?

Afraid I can’t fix it. The real solution needs applying at a level beyond my ability as a programmer. But I know that the maintainer of DR is looking into this, as are some others. There is also a related problem with 44.1k/48k not working correctly at present which is getting some attention.

However a factor which can be involved is being able to do decent ‘upsampling’ out of sight of the user and the actual program that is playing the source material.

In simple terms: The problem is that DR and the ported apps that use it assume the system will accept and play at some sample rates which the newer hardware/HAL doesn’t actually play at present. So DR ends up sending the samples at too high a rate assuming things will be OK. For those who recognise the analogy: bit like playing a Vinyl LP on a turntable that will only rotate at 45rpm. 8-]

The demos of resampling I’ve produced do show some ways to get better results when you need to convert a low-rate input to a high-rate output. But the ‘helium’ effect (which I think of as ‘The Chipmunks Effect’)has two aspects. One is rate conversion. The other is having the machine cope well with more rates and DR knowing what to do for a given system.

My own interest is in better quality even for things that play at the correct speed now. But the better methods I’ve demod may well also be very useful if higher input – output ratios are required to avoid the sound being distorted. I just demod x2, but, e.g. x4 may be wanted if the hardware can’t handle 44.1k/48k and you have 22.05k material to play.

So my demos are aimed at just one aspect of this. They show ways to impliment better resampling, and confirmed to me that the Pandaboard is fast enough to do these resamplings OK.

All I’ve done is write a simple audio file player and an app that will give you a x2 rate output file to play. The real problems are more in the HAL/hardware areas which are beyond me, alas. And as yet it isn’t clear what might be the best approach. That’s something I have to leave to others who know more about the HAL/hardware than myself.

Jim

Add to the above: If you want to examine the programs I wrote you can find them here

The ‘player’ simply sets the sample rate DR requests and tries to use to play out at x2 the input wave file’s rate. I’m assuming the user has something like a PandaBoard that supports 88.2/96k rates, so will play 44.1k material at 88.2k OK. But if a machine supports 44.1k this should mean it will play 22.05k material at 44.1k with better quality than using the standard ‘linear interpolation’.

Once someone understands how the x2 works, x4 is only different in detail. So could be used as needed.

At present the PandaBoards will play 44.1k/48k but in a weird ‘mono’. Again, I’m hoping this will be fixed in some other way. But if not, upsampling to 88.2k/96k will get around the problem.

The reason for the Helium effect is due to upsampling in the digital domain altering the frequency domain. To correct this, you’d need to work out the frequency domain via FHT, FFT or similar and recreate the digital domain.

The issue here is the sheer amount of computation needed to do it, in realtime, and still leave enough cycles for games etc. There are quicker alternatives that sacrifice quality, it all depends on how good you’d like it to sound.

With trackers, the issue isn’t so bad as it can adjust the frequency of the note to account for the output sample rate. It will add quantisation effects, but is probably good enough for gaming.

With regard to tracker modules, 32bit versions are in development by Steve Harrison and myself and will be included with a future version of ADFFS. We have a few beta versions, although until we get the games themselves working on 32bit, it’s a guess at how they’ll sound. There’s a few we can test, which use stock MOD files etc, but they’re in the minority.

The reason for the Helium effect is due to upsampling in the digital domain altering the frequency domain. To correct this, you’d need to work out the frequency domain via FHT, FFT or similar and recreate the digital domain.

Erm… that needs some ‘clarification’. :-)

The problem with the ‘helium sound’ is that the upsampling simply isn’t being performed (correctly) to match what the hardware can play. In effect, the samples aren’t being ‘upsampled’ at all. They are just being played at double (or quad) rate! This isn’t ‘upsampling’ but a clock rate muddle.

You don’t need to “work out the frequency domain” or do an FFT. The demo apps I put up don’t work in that way. They use (audio) industry standard time-domain digital filters, albeit in a very simple form to show the process. And the demos work, showing that something like a PandaBoard can easily do them fast enough to play out the results and produce decent quality audio. My demos use fairly clumsy and unoptimised ‘C’ whereas a decent module would use assembler to run somewhat faster anyway.

Indeed, ‘linear interpolation’ which has been the RO standard method to upsample would work – albeit sacrificing sound quality – if DR was currently able to correctly deal with the HAL problems, etc, which are leading to a muddle over the rate at which samples are played out. So an initial solution may well go on using linear interpolation. And that may be fine for games, if not for decent audio players that also may wish/need to use DR.

Jim

Hi Jon,

I am currently trying to get our game Exodus to run natively on the Pi. It’s using a tracker module too. I would love to exchange some thoughts with you. Is there a way I can get in touch apart from the forum?

Cheers,
Jan

Jon created a forum for this (including private message functions sadly lacking here on ROOL):

http://forums.jaspp.org.uk:9000/forum/index.php

Hi Jan, nice to see you’re still about. :)

I really liked Exodus, so it would be great to see it running on newer machines. Is there any chance for Botkiller1 and Ankh as well?

Hi Michael,

I’d love to get other games running as well but probably I should start with one :) It will be hard enough to find the free time for it. Currently it’s running rather well with Aemulor apart from the sound and some minor effects. There are 10 or so 26-bit modules that I’d need to change though and I’m not sure about the assembler code yet.

Cheers

And Thanks, patric!

I’m now looking at this problem for ADFFS, it’s somewhat more complicated than the discussion above, as it needs to support RO3.5+, work on all hardware from the RiscPC onward and emulate MEMC/VIDC. Essentially it’s (1) taking a 1-8 channel 8bit mu-law audio stream at <22kHz, (2) converting to 16bit stereo and then (3) increasing the sample rate to match the current system sample rate.

Step 3 being the area the OP is concerned with.

Steps 2/3 are provided by SoundDMA with Oversample enabled. SoundDMA does provide a LinearHandler interface which would allow the audio to be intercepted between steps 2 and 3. At this point the audio could be copied to a secondary buffer and interpolated back to the SoundDMA buffer, assuming that all legacy audio needs adjusting.

Later in RO’s development SharedSound was added, this complicates matters as it registers as the LinearHandler. This could be overcome however by proxying the LinearHandler call to SharedSound, once the original buffer has been dealt with. Audio coming from SharedSound itself doesn’t need touching, as far as I can tell, it provides info about the frequency back to subscribers.

The next challenge is choosing an interpolation method, there are literally dozens of methods of which Jim has mentioned a few already. I’m looking at Lanczos at the moment, although I’m open to suggestions on the best method.

I am currently trying to get our game Exodus to run natively on the Pi. It’s using a tracker module too. I would love to exchange some thoughts with you. Is there a way I can get in touch apart from the forum?

Jan, please email me: jon at jaspp dot org dot uk

I’ve just done something similar for another game that’s gone native for the Pi, where we converted bespoke sound modules to WFS (26/32bit sound module bundled with ADFFS) sounds, so am happy to help.

Jon: Done! Thanks!

Cheers,
Jan

FWIW I tend to feel that the question of ‘best’ method for resampling tends to depend on the situation. e.g. resampling ratio and if the rates are above or below about 2 × 20kHz.

So in practice this is probably best decided by what turns out to work well for a given amount of work in implimentation. i.e. what you find you can impliment and works OK. Although in theory the IT textbooks tell you that a close approximation to sinc with many coefficients is the ideal, in practice many people are happy with – or prefer – alternatives.

That said, if you aim to use a ‘modified sinc’ transverse filter method it would be nice to have a file somewhere that defined the coefficients so anyone who wanted could load and use values they preferred. But this is really just a ‘would be nice’ not really vital. Let’s you chicken out of deciding and volley the question over the net to the user, though. :-)

In practice the number of coefficients (length/order of filter) may matter more if you only have a few. Trade off between speed and quality.

Jim

I’m going to try without interpolation first, for that authentic aliasing goodness!

As you point out, the method rather depends on personal preference and the source material. Tracker MOD’s for example tend to exploit aliasing, sound effects however probably need interpolating so they’re not so harsh.

Could the OP try the latest ADFFS to see if it solves the problem. Simply load ADFFS and then try something that previously exhibited the problem.

Whilst ADFFS is loaded it corrects 8bit audio sample rate/buffer length mismatches. It’s designed for games, so doesn’t perform any interpolation, but it could be split off into a separate module and interpolation added if there’s still a need for it.

Could the OP try the latest ADFFS

The link above doesn’t appear to go anywhere…

Found something on http://forums.jaspp.org.uk:9000/forum/viewtopic.php?f=9&t=184 though. Loaded ADFFS on my Panda but still get chipmunks singing on .m4a files, which play at 4500RPM on the Panda; is ADFFS just for the Pi?

Glad to see Jon that you seem to have recovered the Forum postings after your drive failure. Did you manage to get everything back, scans etc?
Or did I misunderstand what you lost?

Do you use a recent version of RISC OS 5.21?

The link above doesn’t appear to go anywhere…

It links to the ADFFS beta forum, I never link directly to the files themselves as I post new betas in separate threads.

Loaded ADFFS on my Panda but still get chipmunks singing on .m4a files, which play at 4500RPM on the Panda

Is the software using 8bit audio, you can confirm by using “RMKill SharedSound” first if you’re not sure. ADFFS doesn’t fix SharedSound as it didn’t exist on RO3.11 (ADFFS is aimed at getting RO2/3 games running on modern hardware)

is ADFFS just for the Pi?

It runs on all OS’s and hardware from RO3.11 up to the latest.

Glad to see Jon that you seem to have recovered the Forum postings after your drive failure. Did you manage to get everything back, scans etc?

Yes, managed a total recovery using some rather nify RAID recovery software

Thanks for the suggestion Jon but I’m afraid “RMKill SharedSound” doesn’t solve the problem with .m4a/MPEG-4 files, either before or after ADFFS (v24.6) is loaded. BTW, I’m trying to play the .m4a file using DigitalCD v3.06, which works OK with .mp3 files. I’m not at all well up on these things – do you have any other suggestions I might try?

NB Sorry, I should have said, my Panda is running RO 5.21 (28 Sept 14) and the ‘riscos’ file in Boot.Loader is dated 24 Nov 14.

It would help me if someone gave a simple explanation of what ‘ADFFS’ is.

I can’t say for other hardware like the RPi. But the Pandaboards used for ARMiniX don’t accept rates below 88.2k. Hence the need for resampling. I guess that ADFFS is meant to do this, but can at present only guess since I’ve not found any detailed description of it.

Jim

It would help me if someone gave a simple explanation of what ‘ADFFS’ is.

Don’t know where/how sound sampling is involved, however the first Google hit for “adffs” is http://adffs.filecore.net/

Perhaps something rather more WTF? is if you try looking to see what is on the main domain: http://www.filecore.net/ Say whut?

I’m afraid “RMKill SharedSound” doesn’t solve the problem with .m4a/MPEG-4 files, either before or after ADFFS (v24.6) is loaded. BTW, I’m trying to play the .m4a file using DigitalCD v3.06, which works OK with .mp3 files

It looks like DigitalCD uses a selection of 3rd party decoder modules to play audio, so there could be a bug in the M4A decoder.

I’ve downloaded a selection of sample M4A files to test, but it doesn’t look like DigitalCD actually supports AAC/MP4/M4A natively – or I’ve simply missed something. There’s no filetype for them in it’s MimeTypes file and no mention of support for them on the DigitalCD site

Do you need an additional module to play M4A?