22050 Hz audio on Pandaboard

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

Look at the JASPP development site for details on what ADFFS is/does.

It’s several things: A 1772 FDC/MEMC/IOC/VIDC/VIDC20 emulator with an ARM3 JIT and a partial hypervisor. I did give a talk about it at ROUGOL earlier in the year, where I went into detail about how it worked. The PowerPoint presentation that went with the talk is on the JASPP site.

The thread on the audio stack is here.

Forget the filecore.net site, it’s really old and I’ve not managed to get a response from Jason to take it own or get it to redirect to the official JASPP site.

The thread on the audio stack is here.

That’s the closest I found to an actual explanation I could read. (PowerPoint isn’t very useful as I don’t use Windows, so would have to switch to a Linux box to try and read one.)

AIUI you’re trying to provide an ‘emulation’ via letting the game or whatever ‘see’ the old SoundDMA/hardware behaviour. However it may be that you need SharedSound in the path if you want it to resample/interpolate, so if you’re bypassing that, you have to do your own resampling. Is that correct?

Jim

That’s the closest I found to an actual explanation I could read.

It was only added and released in the past week and I’ve not had a chance to post a further update to the audio thread with a detailed description, so you’ll have to excuse the lack of detail at this time. It’s certainly not covered in the PowerPoint presentation, which covers the 1772/IOC/MEMC/VIDC1/VIDC20 emulation, how ADFFS interacts with RISCOS and how the JIT translates 26bit instructions.

AIUI you’re trying to provide an ‘emulation’ via letting the game or whatever ‘see’ the old SoundDMA/hardware behaviour. However it may be that you need SharedSound in the path if you want it to resample/interpolate, so if you’re bypassing that, you have to do your own resampling. Is that correct?

The image in the first post is probably all you need in way of an explanation of how it works, I avoided using SharedSound as it overly complicated things. The only emulation happening is of IOC device 9, which isn’t relevant to the OP, more for legacy games and is only active when games are running under the JIT. What it does do is get the Channel Handlers to fill a back buffer instead of the actual sound buffer, and allow Sound_Configure to be set to sizes/periods that the hardware doesn’t support.

When Sound_SampleRate and Sound_Configure are called, ADFFS will proxy the SWI and see what was actually set. It’s level 1 fill which sits between the RISCOS level 1 fill and the Channel Handlers will then make up for the different in buffer size and period when it performs the actual level 1 fill.

The image in the first post is probably all you need in way of an explanation of how it works,

OK, thanks for the info.

Because I have a poor memory I can’t recall for sure. (And I’ve never taken any interest in 8-bit sound anyway.) But I’m wondering if SharedSound would have done the resampling for you, whereas bypassing it and going to SoundDMA means you have to DIY resampling.

Jim

I’m wondering if SharedSound would have done the resampling for you

SharedSound wasn’t an option, quoting my first post on that thread:

The next obvious option is use SharedSound to register a 16bit sound handler, which is how ArcEm works. This however has drawbacks, as far as I can tell SharedSound isn’t freely distributable prior to RO5/6 and there are no distribution points for it left on the ‘net. It also means coding 8bit to 16bit conversion as it doesn’t look like that part was coded in the module – it’s hard to tell as it’s wasn’t formally document when added to RO5.

The resampling is only 11 instructions and handing it off to SharedSound wouldn’t allow me to add an interpolator in the future anyhow.

Probably a dumb idea, but why is it not included in ShareSound (or in the HAL)?

why is it not included in ShareSound (or in the HAL)?

8>16bit conversion?

From memory, I believe the module includes support for it, but its not coded.

SharedSound […] This however has drawbacks, as far as I can tell SharedSound isn’t freely distributable prior to RO5/6

huh? it’s BSD licensed, at least according to where it is in the risc os open source tree

The RO5 version is BSD licensed, the original 26bit version is still copyright ESP so I couldn’t distribute it with ADFFS which pretty much ruled it out as an option.

Could a 26 bit version be backported from the RO5 code?

Could a 26 bit version be backported from the RO5 code?

Bit neutral surely?
A quick glance shows various instances of 26/32 coding and I suspect compiling a suitable version is no great effort.

8>16bit conversion?

No. 22>88khZ conversion :)

No. 22>88khZ conversion :)

I recently started documenting SharedSound on the Wiki, whilst looking through its source code. Unless I’m mistaken, it should already handle any differences in sample rate.

ShareSound, perhaps, but not the OS. Many existing applications have speed problem with sound (all SDL titles for example).

ShareSound, perhaps, but not the OS

If you shell to the CLI and press CTRL-G is the beep the correct pitch? If not, try loading ADFFS and repeat the process. If it’s still wrong, try “*ADFSoundConfigure” and then CTRL-G

I’m trying to figure out where the issue is, it’s still not clear if both 8bit and 16bit are affected.

Can you provide a link to an SDL title? I’ll look to see what its doing.

FYI SharedSound is now included in the system resources download. It should work as far back as (at least) RO 3.1, and should softload OK on RO 5/6 too (although I haven’t tested that)

Can you provide a link to an SDL title? I’ll look to see what its doing.

A lot are here:
http://www.riscos.info/packages/GamesDetails.html

I can’t test them now since my PandaBoard is dedicated to the www.riscos.fr website.
But I’ll soon have a PandaBoard for desktop use.

I remember that RocksNDiamonds and LBreakout2 did have sound problems.

FYI SharedSound is now included in the system resources download.

Great!

I remember that RocksNDiamonds and LBreakout2 did have sound problems.

Whilst browsing to find a copy of the DRenderer module to test RocksNDiamonds, I noted the statement below on the authors site

The DigitalRenderer 0.52 module that comes with the currently released SharedUnixLibrary may playback audio at the wrong speed. It also contains a few bugs that are unlikely to be triggered but may crash your computer. I suggest you replace it with my DigitalRenderer 0.56 beta 8 module.

The version in the ShareUnixLibrary distribution is v0.55 and probably needs updating.

What version of DigitalRenderer are you running? Does the audio problem exist with 0.56b8?

I have no way to try it on my Panda now, since it’s dedicated to my web server. I’ll soon have another panda for desktop use. I just can say that there is no sound problem on the Iyonix with DigitalRenderer 0.55.

If you can test when your other Panda turns up, that would be grand.

I’ve done a fair bit of testing on Iyonix and have seen no issues with any audio that I’ve tried. The issue seems specific to the Panda and is more than likely related to bugs in software, where they’re either not checking that the frequency they’re requesting is valid and when it isn’t, being able to handle the 88k that the Panda offers back.

The issue seems specific to the Panda and is more than likely related to bugs in software, where they’re either not checking that the frequency they’re requesting is valid and when it isn’t, being able to handle the 88k that the Panda offers back.

Yes, that’s exactly the problem. I was just wondering if your software (or over evolutions of RISC OS) could solve this problem…

ADFFS can fix 8bit audio, anything that uses SharedSound will need the original source correcting as its a bug in the code. DRenderer obviously had an issue, which was fixed in the latest release and may explain why UnixLib games all exhibit the problem.

Here’s a summary of things from my point of view:

• The Pandaboard only supports 88.2kHz & 96kHz audio
• SoundDMA has support for 2x oversampling, but it only supports it if both sample rates N and N*2 are supported (this is basically due to the fact that SoundDMA/the kernel places a 4KB limit on the size of each sound DMA buffer. If the automatic oversampling is enabled, and you increase the buffer size/channel count such that the post-oversampling data is over 4KB in size, then rather than reduce the buffer size SoundDMA takes the safer approach of not using oversampling). This basically means that SoundDMA only offers support for sample rates which are natively supported by the hardware.
• SharedSound provides to its clients a buffer filling routine which can perform sample rate conversion. But it’s the client’s choice whether that routine is used or not.
• On June 28 last year I made a bunch of fixes to tempo handling and the builtin voice generators (ticket #347). This means that, e.g. Maestro now plays music correctly no matter what sample rate & buffer size you choose (except for some extreme cases, e.g. “*Tuning Auto” can’t cope properly with sample rates below about 10kHz, due to limitations in how the tuning value is represented in the OS). So as far as I’m concerned the OS is doing everything correctly (although some form of improved builtin sample rate conversion would obviously be nice)
• There definitely are/were some issues with UnixLib/DigitalRenderer. I can’t remember exactly which one was at fault, but when I was adding sound to the RISC OS version of ArcEm I originally tried using UnixLib’s /dev/dsp emulation (which goes via DigitalRenderer, and is presumably the same code path as SDL is using) and found that it wasn’t behaving as it should. Probably something along the lines of it reporting that the sample rate I requested was OK, but then not actually doing any sample rate conversion. I also vaguely remember there being some arbitrary 50kHz sample rate limit somewhere, but I can’t immediately spot it in either the current or older code. Also note that both UnixLib and DRenderer appear to have been changed as part of Christopher Martin’s ffmpeg fixes – so using an old build of a game with a new version of DRenderer might not be enough.

So any remaining problems are likely to be down to games/software asking the OS for a certain sample rate and then not adapting correctly to the rate which they’re given. Whether the correct course of action is to fix the games or add extra oversampling support to the OS is still open for discussion (2x and 4x linear interpolation is certainly easy to support, but there will have to be some improvements made to DMA buffer handling in order to remove the 4KB size limit in order to guarantee that the oversampling can be made available for all current buffer size/channel count combinations)

So any remaining problems are likely to be down to games/software asking the OS for a certain sample rate and then not adapting correctly to the rate which they’re given.

I agree, DRenderer looks to be the issue.

DRenderer in ShareUnixLib needs updating for a start – changes since the version it contains specifically mention playback at the wrong speed being fixed.

Yep that would probably solve problems with SDL applications…

so using an old build of a game with a new version of DRenderer might not be enough.

… Or not.

Nota: StarFighter3000 has also problems with sound on Panda. Not sure it’s exactly the same issue.