audio puzzles, etc

Jim – could you create a series of tests – to help determine – where the change happens? ie:- to be able to run them on the various hardware options RPC/Iyonix/Beagle etc.

That’s in effect what I’ve been doing. In essence I simply apply changes at one stage and then another along the ‘chain’. I’ll explain the rationale below after…

How are you determining the clipping – Ears – or something like !DigitalCD monitor option – external scope?

I’m using a mix of an oscilloscope, an rms meter, and running ROX_scope on one of my Linux boxes. (That lets it accept input via a ‘line’ input and display the results as a scope, and also do FFT-based spectra, show the distortion levels, etc. So a basic audio analyser.)

So my observations/measurements are all on the analogue output waveforms. In essence, oscilloscope and meter measurements.

The rationale for the approach is pretty much the standard one for signal ‘chains’. Imagine a set of boxes (amplifiers) linked in a chain, each with its own gain or volume control.

Assume one box (amp) in the chain is clipping the signals. Test with a sinewave so you can see ‘flats’ appear on the top/bottom of what should be a pure sinewave. An FFT shows the harmonic distortion this creates (and I can measure a THD that has risen).

if you vary the gains of the boxes (amps) after the guilty one, the size of the result changes, but it remains clipped, shows the same flattened shape, and still gives high distortion.

However if you reduce the gain of a box (amp) before the guilty one, the waveform gets smaller and the degree of flats becomes slighter. Wind down this enough and the output loses the flats, isn’t clipped, and the distortion is very low.

So by experiment, you can determine where in between which boxes or stages in a chain the clipping is being introduced.

FWIW The Iyonix also clipped. But that seemed to be right at the output and wasn’t anything like as severe as I’m getting with the current ARMiniX/PandaBoard setup. I don’t think the RPC did clip early. But it is too long ago since I used one, and I only ever used external cards with it, and not for audio.

Clipping can be missed when listening if you aren’t careful. Depends on the circumstances and if you are on the alert. The effect tends to cloud or degrade the sound, but it may not be obvious that the effect is clipping. So the safest course for many such audio hardware problems is to poke about with a scope/meter/FFT and some test waveforms. That’s the injuneer in me speaking. :-)

So the snag is that someone really needs to connect up a scope or similar to really know what is happening. They may feel the sound isn’t as good as it could be, but assume “That’s what I get” and either assume it is good as possible or place the blame elsewhere.

Jim

I don’t think the RPC did clip early.

I think it’s safe to assume that Acorn went to some lengths to ensure it did the right thing, though I do recall a simple mod that removed some filtering to “improve the high frequency response”. Whether that was actually a good idea or not (especially with different numbers of channels) is another question.

Though I did do quite a bit of audio programming on the RPC (including wavetable synthesis for Hasbro) and still have the oscilloscope somewhere, I don’t recall plugging the RPC’s output into it or observing anything odd if I did.

Look at the G.711 tables for mu-law. 127 corresponds to a decision value of 8159; 100 to a decision value of 2527. The ratio of those numbers is 0.308 or 3.24 depending which way up.

Accepted. I tend to use/suggest a *volume of ‘100’ simply as a round and easy-to-recall value that avoids the problem. I think you can push the number up to about 102 or 103 in practice.

It is hard to be sure about the exact value so at present I can only specify with an accuracy of about half a dB. The problem is that the effect of slight clipping is a small rise in distortion even before the ‘flats’ become visible. So you have to choose at what point is this ‘clipping’. Made vague because many systems show a rise in distortion as you get very close to max anayway.

The problem I have is that I can specify what happens to the output. And I can say it looks like being in a given ‘section’ of the data chain. But I don’t have the skills to read the assembler and spot the bug. That’s where I need help from someone able to do that based on what I’m explaining about the symptoms.

BTW I’m listening to a series of tracks of ‘La Traviata’ from the Met as I type this. Using my nice new – finally in a box with an LED indicator and volume control – amp + filter. Sounds Good. But I think it could be better. :-)

Jim

Though I did do quite a bit of audio programming on the RPC (including wavetable synthesis for Hasbro) and still have the oscilloscope somewhere, I don’t recall plugging the RPC’s output into it or observing anything odd if I did.

At the time my main interest was in using the RPC for recording/collecting waveforms from (lab) instruments rather than making audio recordings or using it for playback. So my focus tended to be via some of the plugin cards for recording. I did test various cards and we ended up using some supplied by Intelligent Interfaces. These IIRC were ‘Wild Vision’ ones, but Andy Ray and ourselves had to modify the firmware to make them sample at a uniform rate rather than in ‘bursts’. I can’t really recall details of the audio out of the RPC, but so far as I recall, it didn’t clip like I’ve getting at present from the ARminiX. So I think Andre’s comments wrt are correct.

Hence part of what makes dealing with this problem harder is that people may check using a RPC or Iyonix and not get the same behaviour. To me, this looks as it if it specific to the ARMiniX / PandaBoard. Alas, that means someone else may need one of these to check, along with something like a scope or analyser.

This is all frustrating as the PandaBoard does seem to have good audio hardware that goes up to 96k/24bit. If we can deal with these stumbling blocks and be able to feed date cleanly to the audio chip (and maybe improve the oversampling) it would be the basis of a really excellent audio player.

TBH I’ve been hoping to feature this in my column in the ‘Yearbook’ issue of Hi Fi News magazine. My point being that the ARMiniX and similar systems are the ‘highlight of the year’ to me in audio terms. i.e. be able to rank this beside some of the top kit people queue up to buy at high prices. Should generate some interest and attract new users. Open up a fresh field.

But with these problems unresolve I’m left dithering between giving a more cautuous welcome or simply delaying to another issue. I can still feature it, but it may have less impact. Shame as I’d love to do this soon after a feature they’re publishing on Linux audio that I wrote for them. Hence my anxiousness to see if this can be looked at sooner rather than later.

Jim

Jim

…and still have the oscilloscope somewhere, I don’t recall plugging the RPC’s output into it or observing anything odd if I did.

FWIW When I examined the output from the Iyonix the main problem I found was down to its hardware insisting on running the output sample clock always at 48k. It ‘resampled’ 44.1k (i.e. audio CD material) on a simple ‘repeat the last sample if you haven’t got the next one yet’ basis!

The result was pretty high levels of anharmonic distortion if the input contained much in the way of the higher audio frequencies. In my mind it ruled it out totally for any serious hifi purposes since 44.1k dominated at the time.

But personally, I’ve only taken ‘computer based’ audio seriously in the last 3 years or so since the growth of higher resolution material, and factors like the iPlayer. (Which is actually at 44.1k sample rate despite the BBC internally using 48k/24bit for distribution.) The iPlayer and BBC radio does tend to run though a series of rate convertors that aren’t locked. But being the BBC they tend to use good kit, so the results can be good when people like the R3 teams use it.

Jim

I do recall a simple mod that removed some filtering to “improve the high frequency response”.

Wasn’t that for the VIDC2 to help sharpen up the RGB outputs or something? Video, not audio, unless my recollection is screwy.

This is what I’m thinking of:
http://www.jrmiller.demon.co.uk/rpc/mods.html

Couple of quick updates:

1) I have tried using the ‘PowerBars’ plugin with DigitalCD. System *volume set to 100. I then played a -6dBFS test (sinewave) file. DCD’s own volume set to ‘100%’. The result plays fine and output is OK. If I change the *volume to 127 the result is clipped. However the bars still only go half-way up their ranges.

Changes in *volume alter the output, but don’t change what the bars display. They seem to show what the file provides with DCD gain set to 100%.

2) When I did the above I was using headphones to monitor the output, not a scope, just for quickness. I noticed that the tone developed a very noticable ‘nasal’ quality. It occurs to me that the clipping is gross enough that it should be easily audible if someone uses a test tone and listens using decent headphones, etc.

So people may be able to do a rough check without any measurement kit.

You can use the !WAV_Gen program from my audiomisc website’s software page to generate some test tones. That’s at

http://www.audiomisc.co.uk/software/index.html

I’d suggest a 300Hz mono sinewave with a -6dB amplitude. Try also with a 0dBFS version. For the ARMiniX I’d suggest either 44.1k or 88.2k sample rate, 16bit and have your ARMiniX system sample rate set to 88.2k to ensure you avoid interpolation distortions in the audible range.

Play the tone with a system *volume of 100 and with DCD set to 100% gain. It should sound as a clean sinewave. Halt playing and change to a *volume of 127. Play the tone again. If you have clipping it will sound as if the signal generator is pinching its nose and making a quacking tone.

[Note added later: Occurs to me that – for those familiar with the sound of orchestral instruments – the clipping changes the tone as if “turning a clarinet into an oboe!” ;→ ]

Be interested to see if people can replicate this. My guess is that it will show up on ARMiniX/PandaBoards but maybe not on other machines. That said, if you want to try this on an Iyonix I’d suggest using 48k sample rates for the files and system setting. Otherwise you’ll get distortions for other reasons.

Jim

Rick asked

Wasn’t that for the VIDC2 to help sharpen up the RGB outputs or something?

Actually now I come to think of it, it may have been pre RPC – an Archimedes A310 mod. Crikey I’ve been doing this a long time.

– an Archimedes A310 mod.

Out of interest, do you have any info on this? I looked on Google and found a lot of stuff about Airbus…. :-D

Well, if the thread is going to drift in that direction I may as well add a roll to the side… The closest I can get to 310 Airbus was…

http://jcgl.orpheusweb.co.uk/history/concorde/ChaseTheSun.html

;→

I can drag it back to ‘audio’ that way, though, as I used a Revox A77 to record the data. :-)

Jim

Out of interest, do you have any info on this?

Nothing concrete. I think it was as simple as removing or snipping the leg of a capacitor, or a resistor.

Crikey I’ve been doing this a long time.

You the old one about “you’re getting old”?

update, TomTom mode: “You have reached your destination” :-)

For Jim – I think you have an audience of audiophiles and musical types on c.s.a. – perhaps they could assist. Possibly even join in here.

For Jim – I think you have an audience of audiophiles and musical types on c.s.a. – perhaps they could assist. Possibly even join in here.

I have raised some of this on the c.s.a groups, and in other ways. I can describe some of the ‘tests’ there for people to try, etc. However the main reason I joined the forum was that I was told in a fairly definative way that those who are able to read/analyser/modify the probably-relevant code would be far more likely to react if I raised the issues on this forum.

So far I’ve seen some discussion and feedback, and some info. e.g. from Jeffrey – on various aspects. But as yet it remains unclear to me if anyone working on the relevant modules, etc, will do anything to find the crux of the behaviour and fix it.

As I’ve said, I can do some tests, but I can’t make sense of the assembler – and in some cases can’t even find a copy! So I can’t pinpoint where in the code the problem may arise.

I asked last night on c.s.a.programming about one specific issue wrt this.

I am trying to use the SoundControl_ swis to check what settings the mixer has for myself to see if there is something odd. But I can’t get the swis to work as advertised. This is probably an error on my part, but I haven’t yet found it. So advice would be welcome. (I’m using the ‘Acorn’ compiler. which hasn’t been updated for the relevant swis, so have to call one swi to get the number for the swi, then use that. Doesn’t work at present. Indeed, I then tried one of the other SoundControl_ swis and that didn’t work, either. No idea what I’m doing wrong! ]

I started this in the ‘General’ area because I wasn’t sure what was best. Should I raise it on the ‘Bugs’ area?

Jim

as yet it remains unclear to me if anyone working on the relevant modules, etc, will do anything to find the crux of the behaviour and fix it.

The number of active developers on RISC OS is tiny, and they’re swamped with stuff to do. There are lots of cases where bugs raised here have led to fixes (e.g. the USB modules), but there’s no guarantee that people can drop everything to look into a problem, particularly as no-one’s getting paid and they all have day-jobs or projects ongoing in other areas.

My recommendation would be:

- Use this thread to continue discussions for what might be the problem. Someone may turn up who can assist properly. My guess is that very few people understand the sound system in any detail, and they’re all likely to be oversubscribed with other things, so don’t assume lack of definite responses within a short time-frame means lack of interest.

- Use the Bugs thread to report issues as concisely as possible. The more specific you can be here the better – it’s less for discussion and more for highlighting problems that can then be investigated and fixed.

- Consider working on a bounty for the RISC OS sound system, similar to those proposed for the Filesystem and USB. If you can get to the bottom of what needs to be fixed, and provide a clear and concise list of some desirable improvements, someone might be tempted to take it up, and give the whole structure an overhaul.

The number of active developers on RISC OS is tiny, and they’re swamped with stuff to do. There are lots of cases where bugs raised here have led to fixes (e.g. the USB modules), but there’s no guarantee that people can drop everything to look into a problem,

Appreciated and accepted, fair enough. I’m just hoping that someone with the ability will say they’ll look at this when they can. And then hope it is at least reasonably soon. So far as I can gather this is a ‘new’ problem that didn’t occur with the Iyonix or RPC. My (ignorant) suspicion is that it is a simple ‘oops’ somewhere. But I appreciate it may take time to spot.

I tried a bounty a few years ago. Didn’t get me anywhere. However if someone will say they’ll fix this for, say, 100 quid, I’d put up one. However my impression from before was that people just work on what interests them, regardless. Which, again, is fair enough, but I’d like to see this sorted as we are now so close to having a RO box with truly superb audio performance. Seems crazy not to capitalise on the new market and users that could draw in. At present I can’t tell if I’m simply wasting my time trying to narrow this down because no-one will bother to try and fix the problem anyway. They may intend to, but I have no real feedback on that.

At present is is possible that the behaviour is down to a simple mis-configuration slip somewhere. Hence my wanting to probe SoundControl, etc.

BTW I just scanned the machine for swis. Found out why my SoundControl probe wouldn’t work. The prefix isn’t SoundControl_ as given in the API. It is SoundCtrl_ … I decided the swi name must be incorrect because trying to get a number from the name gave random results. So I did a scan, and found this out.

Jim

I’m just hoping that someone with the ability will say they’ll look at this when they can. And then hope it is at least reasonably soon.

I think I’ve now learnt to avoid offering to do things like that. “soon” either ends up being several months away, or I just end up getting stuck forever doing things other people want me to do instead of things I want to do (or that’s what it feels like, at least).

But having said that, this is something I’d like to see fixed. So once I’m finished with my GraphicsV changes (several months away) I might take a look into this, depending on how much other stuff crops up in the meantime.

At present I can’t tell if I’m simply wasting my time trying to narrow this down because no-one will bother to try and fix the problem anyway. They may intend to, but I have no real feedback on that.

I’d say that what you’re doing is of mixed use.

Problems with third-party apps (e.g. DigitalCD being influenced by *Volume) might be things that an OS developer would miss – e.g. my BeagleBoards, Raspberry Pi, etc. are all very much “development machines” and don’t have much on them except the base RISC OS install. So if I was testing gain settings being applied to 16bit sounds I would have probably written code which interfaces with SharedSound or the 16bit sound handler directly, due to not having any music player installed. Plus it’s a good way of making sure I know I’m feeding the correct data into the system – a third-party music player could be doing almost anything to a wav file it’s been asked to play, and without scouring the source myself I’d have no idea if samples are being passed through correctly or not.

But other things you’re doing may be redundant. I can’t speak for other programmers, but when/if I was to look at this issue I’d be tempted to do a full audit of the sound system – measuring each platform to make sure gain settings are being applied correctly by each subsystem, and documenting any settings that result in clipping. So narrowing down the exact cause of the problem yourself might not be useful, especially since whoever offers to fix it would want to be able to test the fix themselves – so they’ll need a testing setup of some kind, with before and after results to make sure the fix is working.

BTW I just scanned the machine for swis. Found out why my SoundControl probe wouldn’t work. The prefix isn’t SoundControl_ as given in the API. It is SoundCtrl_ … I decided the swi name must be incorrect because trying to get a number from the name gave random results. So I did a scan, and found this out.

Interesting – I’ll try and remember to update the docs when I get home tonight.

Hi Jeffrey,

Accept what you say about being wary of terms like “soon”. Fair enough. For me, just having you say you’re minded to look into when you can is an advance/help from having no idea if anyone takes the problem seriously or would ever look at it. :-)

Problems with third-party apps (e.g. DigitalCD being influenced by *Volume) might be things that an OS developer would miss – e.g. my BeagleBoards, Raspberry Pi, etc. are all very much “development machines” and don’t have much on them except the base RISC OS install. So if I was testing gain settings being applied to 16bit sounds I would have probably written code which interfaces with SharedSound or the 16bit sound handler directly, due to not having any music player installed. Plus it’s a good way of making sure I know I’m feeding the correct data into the system – a third-party music player could be doing almost anything to a wav file it’s been asked to play, and without scouring the source myself I’d have no idea if samples are being passed through correctly or not.

FWIW My feeling is that the problem isn’t in the playing apps or drivers (although I do see signs of some other snags in them). I get the same problem using different players and different drivers. My current vague suspicion is that the problem may be in the SoundControl module, or at least the way its settings are being applied on the ARminiX/PandaBoard.

But other things you’re doing may be redundant…. So narrowing down the exact cause of the problem yourself might not be useful,

I’m sure some of what I’ve done is redundant. The problem is the only way to know is to try things to see what I can find that points to some areas being irrelevant. Standard engineering approach to diagnosing a problem with a signal chain. I’d expect anyone working on this to do their own tests. But I’d also expect their findings to be compatible with my own findings wrt behaviour even though I can’t diagnose a cause, only produce some evidence that may help exclude some areas and make some others seem more likely to be fruitful.

And whilst you and others are busy/occupied with other things I may at least be able to find optimal ways to minimise the effects and ensure users can get the best they can. Avoid people getting poorer results than necessary. Although setting some other gain like *volume to a lower value does duck the clipping I’m not sure if this is the best avoidance, or what effect it has on low-level signals in terms of quantisation, etc. May be a better ‘pro tem’ strategy. Which means examining things.

FWIW I’m now getting results from the _ExamineMixer and _GetMix swis. In themselves the values make sense, but there is one aspect that puzzles me at present.

ExamineMixer tells me the range of the MixVolume control for system goes up to 24dB – as per the value you gave some time ago when I didn’t know where the value came from.

GetMix tells me the set gain for system is 0dB.

Both fine. But…

If I look inside Boot at the Boot.PreDesk.SndSetup obey it lists a series of MixVolume setting values. For system this is all zeros.

Does a zero for MixVolume applied to system mean a gain of 0dB, or a ‘max’ or a ‘min’, or what? I’m not clear on this and I’m wondering if a gain above zero might actually be represented by a 0 for MixVolume when the range goes up to 24dB.

Jim

For anyone interested I’ve now put a zip of my small progs that probe the SoundControl module up at

http://jcgl.orpheusweb.co.uk/temp/scprogs.zip

Anyone is welcome to use them as they wish.

Jim

ExamineMixer tells me the range of the MixVolume control for system goes up to 24dB – as per the value you gave some time ago when I didn’t know where the value came from.

I took the values from the OMAP4 HAL sources (All that SoundControl does is pass the settings through to the driver in the HAL, which applies them to the hardware)

Does a zero for MixVolume applied to system mean a gain of 0dB, or a ‘max’ or a ‘min’, or what? I’m not clear on this and I’m wondering if a gain above zero might actually be represented by a 0 for MixVolume when the range goes up to 24dB.

MixVolume uses the same units as the SetMix/GetMix SWIs. So a MixVolume of 0 is 0dB, 16 is +1dB, -16 is -1dB, (24*16) is +24dB, etc.

Just to update anyone who has missed comments on the ‘Bugs’ subforum…

The present state of play is that it looks plausible that the clipping (like the problems with lower sample rates) may be arising due to problems in the HAL. Causing what arrives at the hardware to not be as the drivers/modules think they are specifying. The ‘messages’ seem to be mangled or lost on the way.

An example may be that when I try to use the *MixVolume 0 0 0 0 <N> to change the mixer’s (i.e. hardware chip) gain, the modules report the changed value but the output isn’t affected. No change in actual output volume despite the SoundControl module thinking that the gain has been changed.

Investigations continue…

Jim

Would it worth trying this?

Find out what sample rate – the ‘Panda’ sound hardware takes as default?
Does it need a buffer?
Make up a fairly simple single tasking prog – that just pokes a known good sample – of the the default rate to the hardware sound swi’s – closest to the hardware.
Loop around – taking a keyboard input – so the volume/etc levels can be read and updated.
Listen or scope the audio output – using the keyboard to change levels.
And see what the result is like.

I have tried using PlayIt more directly than via a playing app. You can use it via either star commands or simply ‘one instruction per program’ BASIC or ‘C’ proglets. Whilst doing so I have experimented with the effect of *volume etc. The behaviour is much the same as I’ve described.

FWIW there are some problems with the way PlaySound+PlayIt handle the *volume. Someone is looking into that as a distinct issue from what I’ve raised here as we think we know the reason. It affects how it uses the *volume command. But not the clipping.

FWIW2 The Pandaboard certainly takes 88.2k/96k and both are easily usable. There is a different of opinion / muddle at present wrt 44.1k/48k. The original HAL assumes not, so ‘bodges’ provision in a way that messes up performance. This is almost certainly fixable one way or another.

AIUI the audio goes though DMA buffers, normally fed by the driver you are using – e.g. PlayIt. Given the behaviour we’ve established it seems unlikely that is the cause of the problems. But I can’t be sure until the problems are finally fixed. :-)

Would it be of interest if I put up some simple instructions on how to use PlayIt as I have outlined? I could put something on the web if you or someone else wishes to try it. But if you look at the help for PlayIt it tells you.

FWIW3 I may sometime try writing my own modified driver to see if I can do something about some of the other issues. e.g. interpolation control. If nothing else I’d find it a learning experience. :-) But at present I’m resolving that with a post-DAC analogue filter that passes up to 23kHz and suppresses the ultrasonic hash. That also kills the DAC hash, so is arguably better. But of course means someone has to add such a device to the output.

Jim

Just as an update:

I’ve now put up a webpage in the external amp/filter/volume control I’ve made for my ARMiniX. May also be useful for some other machines to ‘clean up’ the analogue output and give a volume control.

http://www.audiomisc.co.uk/RO/SoundsGood/PassTheMusic.html

Oh, and if anyone wants to read some of the old ‘Archive’ magazine articles on audio and things like resampling, they are at

http://www.audiomisc.co.uk/ArchiveMagazine/index.html

Jim

Your external volume control reminds me of one of the innovations that made the Synclavier (PMST model) the apotheosis of 80s digital synthesisers. Not content with 16bit DACs – 16bit 100kHz DACs mind you – it used two per voice for stereo and, instead of achieving volume modulation (enveloping) in the digital domain, employed a digitally-controlled analogue VCA per DAC.

This is why the bare-bones system started at $75,000 and could reach half a million for a full digital studio setup. I expect your hardware is slightly more economic.