How to do USB audio

If the external hub you plug your keyboard into is USB 2 then thats no problem the output from that is USB 2 if it is USB 1 then yes it ‘may’ have been a problem but putting the audio device on another hub on its own would bypass the problem. USBModule should cope with the situation anyway – but it’s early days :-).

Your keyboard isn’t a problem.

Is the socket on the back of the arminix a direct connection to the board?

Can you get a decent size music file on a ram disc to see if you still get pauses?

I’ve updated the USBAudio archive at http://davehigton.me.uk/Audio

The USBAudio module is updated to code round the defective descriptors in Jim’s ARCAM DAC. I hope I’ve done it in a way that doesn’t break anything else.

Reports from any and all testers would be welcome!

On my Iyonix 5.20 I get a request for a later USB driver,
Is there also a link for a driver replacement from Colin perhaps?
I have got the go-ahead to pick up a Turtle Beach dongle,
so I will report back after trying it.

Is there also a link for a driver replacement from Colin perhaps?

Yes, only a few messages back in this thread.

OK, tried this Turtle Beach Advantage (C-Media) on my Iyonix 5.20 and it is OK with both playing methods as long as the wav is 48000Hz.
I had a recording from !AudioIn otherwise I might of missed that, as most my wav conversions are from a 44100 origin.
With a 44100 wav Dave’s player error’s with
‘No matching parameter set at line 1580’
Colins player plays but introduces static and the sound is muffled, I guess this is the result of forcing 44100Hz sound through a 48000Hz device.

The RasPi 5.21 is a no go
EDIT: removed data as this is well known about.

Your device is 48000hz only so IsocPlayer and Dave’s player will only play 48000 wav files. They don’t do any sample rate conversion and you can’t just feed the audio devices with the wrong sample rate data you have to do a sample rate conversion of the whole file.

So the failure of Dave’s Program is a success for him as it correctly identified that your device won’t handle 44100 files

The pi won’t work. That is the only device that doesn’t use the EHCIDriver that I am modifying at the moment.

Colin: I’ve now tried playing wave files from ramdisc. Still get the pauses. Makes no difference I can notice.

AIUI Yes, the sockets on the rear of the ARMiniX are actually on the PandaBoard. Whereas the ones on the front panel go via an ‘external’ (i.e. off-board) hub. The ones at the front seem far more reliable and flexible.

FWIW my keyboard is a problem as it seems not to suit the rear sockets. :-/ But it seems like this isn’t a factor here. Although I do get the ‘added clicks’ when trying to use the rDAC from the rear sockets.

Dave: Just tried your new player/module with the rDAC. Results interesting. It will play a 96k/24 bit file – with the pauses. But not play a files that are 16 bit. So I assume from that the rDAC is wanting 3byte samples?

With my DAC Magic Plus (Class 2) your player won’t play anything. Whereas Colin’s !IsocPlayer plays fine any rate/depth I try, no pauses.

In each case when it fails, your player gives “no matching parameter set at line 1580”. So again I guess this is because the DAC Magic Plus wants 4byte values.

Jim

Dave you are going to have to change that error to ‘Audio format not supported by your device’ or something like that :-)

Jim you may as well try USBModule.zip it may fix the crackling from the back socket.

Dave if you’d like to try the above set of modules on your beagleboard does it stop the sluggish mouse? If you’ve shut down for xmas it can wait until the new year.

Dave you are going to have to change that error to ‘Audio format not supported by your device’ or something like that :-)

I think that’s a good idea!

I guess this is because the DAC Magic Plus wants 4byte values.

Probably. In order to get it to work, you’d have to process some source material to a 32 bit stereo WAV file, but then edit the header to state 24 bit resolution while leaving the number of bytes per sample unchanged.

These DACs are a damned nuisance. Shipping 32 bit samples around is one thing, but the ease of transmitting them is outweighed by the difficulty of bulking them out from their natural sample size to an artifical one.

I may have to change the matching rules for the sampling parameters, although there’s an argument for leaving it to the player or recorder application.

I’ve just added a SWI to the USBAudio module to enumerate the sample rates of a device, in a form that an audio application can easily understand. I need to test it a bit more, then I’ll put it up on my web site along with a test app that uses the information. Clearly I need to document it, but writing the HTML is likely to take longer than coding the SWI did. Anyway, as I’m sure you all know by now, I’ll keep you posted.

If you’ve shut down for xmas it can wait until the new year.

I haven’t shut down, but I need to spend some time with other people over the next few days, so I may be delayed a bit.

but I need to spend some time with other people over the next few days

Yeah, me too. A bloke known only as “the Doctor”, a cutie called Clara….. ;-)

Merry Christmas (or other denominational celebration) everybody!

Recent developments has allowed libsndfile to compile and run. This has also allowed sndfile-resample to work. For example, *sndfile-resample -to 48000 dark.wav newdark.wav (dont forget the – in front of to).
It has a choice of 5 interpolations.
I also included sndfile-info in this archive.
http://homepages.woosh.co.nz/ron.may/libsndfile.zip
If any of the remaining binaries from libsndfile are of interest just ask and I’ll put them up.

From a different place, I have compiled sr-convert.
http://homepages.woosh.co.nz/ron.may/srconvert.zip

Both claim to use high quality techniques, but they take a long time on my Iyonix.
sr-convert source has some neon assembler options so it may be possible to compile a linux raspberry version if speed on familiar hardware is a requirement.
The sample rate conversion only needs to be done once, the question is which method is the best choice? Maybe Jim will get interested and give a critical (re)view (-:

Maybe Jim will get interested and give a critical (re)view (-:

Yes, interested. Can you say more about the sources and details? Also about the interpolation methods and what the “developments” were?

Currently having a bit of an xmas break, but aim to pick things up again soon! :-)

Jim

For resampling, there is always the “Shibatch Sampling Rate Converter” aka ssrc. It was ported some time ago by Stefan Bellon, it is 32bit ready but probably not ARMv7. Source and binary can be downloaded from Stefan’s site: http://www.sbellon.de/archives/ssrc.zip

The ssrc source handbuilt makefile converted easily for !GCC so I have made a binary that should be OK on ARM7.
I haven’t come across the use of the stubs lib so I left it out and got no complaint from the compiler.
EDIT: It is stopping with ‘unknown error 4’ so I will have to perhaps introduce some compiler switches to
find the problem.

Jim, regarding libsndfile, I found that the very latest changes in recent months available only by git are opening the files properly. Earlier versions were jumbling the wav header info or something.
There is another resampler called fsrc (libfsrc) but it uses cmake throughout, and without lengthy conversion, the result is for the crosscompiler to output an x86 binary. It uses the fftw3 library (fast fourier).

I suppose one could compare the resampling effort from sox(tried) or ffmpeg(untried) also. I have no facts to say for sure that they would be lesser than the specialised programs, I’m just expecting so.

EDIT: I downloaded the original source for ssrc and it practically compiled straight out of the box. There is a high precision version included also.
http://homepages.woosh.co.nz/ron.may/ssrc-gcc.zip
I have to wait an hour for a track to convert so I can give it the final test, but it appears to be working OK so far.

FWIW my reference point/method for rate conversions, etc, tends to be the way sox does this. Based on SRC which I think is also the ALSA default approach for high quality. Generally found this works very well. That said, I’m referring specifically to the Linux version of sox as I’ve not checked the RO port against it.

Jim

These file in file out programs should have the same output in the RISC OS ports, one check would be to compare the output files. With archiving tools a reasonable check is just to compare the file sizes.
I dont know wether any randomness is used in any of these wave conversion programs, but they seem to be using mathematical models which you would think should calculate the same, floating point or hardpoint/neon etc on all platforms.
So that would be one form of check, and reviews on other platforms could be helpful.
I seen mentioned somewhere the use of a signal to noise ratio check, but I’ve been thinking, that if someone had good recording gear, that if the same signal was recorded in 48000 and 44100 then the 44100 signal after various resamplng might be able to be compared to the untouched 48000 sample for likeness.
There is one tool in libsndfile called sndfile-cmp but I haven’t looked at it’s capabilities yet.
There are quite a few possible techniques possible with variations within each program.
They all take a long time to do a conversion, but this shouldn’t be a consideration, as they can run in the background, or on a RasPi overnight.
The ssrc program appears to have an option for selecting a temp file.
I am trying yet another technique for putting scrap in RAM. I have found that by using the RAM creation line from !Boot at the start of The !Scrap !Boot an !Run files, that the directory for scrap can then be set to RAM::RamDisc0. One complication has always been !Netsurf’s use of !Scrap, but I have a line in Netsurf’s !Boot to copy the WWW and RUfl-cache to scrap if it is not already there. Any changes to fonts will need the file deleting and re-establishing manually, but so far so good.
I mention all of this because I have had to use disknight a few times on sdfs, which could be down to the type of card, or even psu problems, but the more memory can be used instead of flash the better I think.

I don’t know wether any randomness is used in any of these wave conversion programs, but they seem to be using mathematical models which you would think should calculate the same, floating point or hardpoint/neon etc on all platforms.

I can think of two reasons why the files may vary: Differences in accuracy and variations in rounding. But it’s worth trying I’d have thought.

‘I can think of two reasons why the files may vary: Differences in accuracy and variations in rounding.’

I’m not sure what you mean here. But the subject was wether !GCC output from another platform gcc output, using the same c source code, in one instant, and perhaps different if non floating point hardware is implemented.
You make it sound like !GCC/arm chip could have a different digital size or resolution to say an gcc/X86.
and wouldn’t !GCC/gcc treat an overflow the same in both cases?

I’m no C expert so you almost certainly correct. I was thinking that the algorithm used would be honed for speed to be just as accurate as to get the last significant digit and no more. Your “converted easily for !GCC” made me think it was using a different compiler.

I’ve not had time to check any of the above as yet as I’m otherwise busy at present. However I do have progs already to let me compare different examples of output – e.g. by doing a sample by sample subtraction. So I can check when I get a chance.

WRT dithering or noise shaping differences. This may depend on the ‘random’ functions used. I don’t know if these work identically for the different compilers on different platforms. I use GCC for Linux but the ‘ROOL’ compiler for RO, but not compared them on this.

FWIW sox always applies simple triangular dither by default, and that’s what I tend to expect. So I’d expect no more than a ‘randomised’ difference in the last bit if all else is equal. However it will depend on all the other details of the algorithms use. Devil in the details.

BTW I’ve not knowingly used libsndfile before, so I’ll ask two questions.

1) Any documentation for command line use?

2) Is this GPL or similar? If so, should not the sources, etc, also come with a compiled version? That would help me although I’ve had a quick look on the web at some of the stuff on it.

Jim

One thing I noted is that it looks for the .wav extension otherwise it wont open it.
This is the way to get the libsoundlib group.
Eric de Castro Lopo is the author, and is heavily involved in flac development also by the looks.

git clone git://github.com/erikd/libsndfile.git
svn co http://svn.xiph.org/trunk/ogg
svn co http://svn.xiph.org/trunk/vorbis
git clone git://git.xiph.org/flac.git
and libsamplerate
www.mega-nerd.com/SRC
www.mega-nerd.com/SRC/libsamplerate-0.1.8.tar.gz

I needed the git version of libsndfile for the cross-compiler to produce a working RISC OS binary but on Linux you can probably use more conventional program installing methods.

Using apt-cache search libsamplerate
shows that there is also a related package called samplerate-programs that I haven’t tried.
Also there is an unrelated C++ library called libzita-resampler1
A comparison is here.
http://kokkinizita.linuxaudio.org/linuxaudio/zita-resampler/resampler.html

Possibly sudo apt-get install samplerate-programs would install all of the dependencies in one hit.

Chris, Yes there is some confusion regarding the source code that Steffen supplied a link to. It had been modified for the Norcroft compiler and I simply changed the small makefile to use with !GCC. This source did not work, so I downloaded the sourceforge source for the same project, and apart from adding the -static flag and adding an #include for string.h
it then compiled with !GCC straight off.

The libsndfile source has a test suite suitable for cross-compiling output, and with a little fixing I got the test suite on the Iyonix. I changed the linux shell script to an Obey file and have got it running the tests.
There is an alarmimg failure with the float_scaled_test.
My laptop returns -500db on that line so the error SNR’s are strange looking to say the least.
The program seems to work, but it might be better to wait until something comes to light on the subject.
Here is the text output from the test
http://homepages.woosh.co.nz/ron.may/sndfile-test.txt