How to do USB audio
Pages: 1 ... 40 41 42 43 44 45 46 47 48 49 50 51 52
jim lesurf (2082) 1348 posts |
That makes sense to me. The significant point of course is in your rider. That you’re only talking about the USBAudio module here. But that still leaves the question of determining the cause. And perhaps the fact that the order of events matters may help resolve that. I’ve been assuming that replacing the default USB modules with Colin’s does, by default, reset every device. But maybe it doesn’t? Or might the standard modules confuse the audio device in some way before Colin’s versions are installed? Afraid all I can do here is ask questions as I don’t understand the modules. I’ll read JW’s article and get back to you… :-) Jim |
jim lesurf (2082) 1348 posts |
Yes – as you’d expect – it’s a good article. I agree with almost everything he writes. I also agree that a lot of audio kit is priced on the ‘Gucci’ principle. Listen to this week’s “Business Program” on R4 to see what I mean. However he does omit a few relevant details. And yes, I know about the JAES report he mentions (and others) showing that in well controlled tests people can’t hear differences. However reality isn’t always that simple. As he points out, higher bit depths make sense when recording as it gives more room to avoid clipping and signal levels that are too low. Ditto for higher sample rates. That means less chance of intersample peaks above 9dBFS. Unfortunately, problems can arrive when you start considering real commercial players/DACs and CDs. e.g. the tendency for many CDs to clip or generate intersample peaks above 0dBFS, and for some DACs to distort these even when the sample series defines an unclipped waveform correctly. Similarly, the risk of some kind of aliasing problems or HF roll-off. The point about the AES tests is that serious engineers, etc, tend to use good kit, and use it with appropriate methods. Alas, that may not be true for all home users. We also have the problem that when the ‘music companies’ (sic) re-release material they tend to tart it about. So it can ‘sound different’ anyway. The real problem here is that not all kit (or CDs) are done perfectly to the limits of what is possible according to information theory. In addition, one point he makes I would alter. Human hearing isn’t simply non-linear at ‘high levels’. It is inherently non-linear over a very wide range of quite normal levels. And even modest average sound levels contains surprisingly high peaks for a lot of acoustic material. And as with vision, the details vary a lot from one person to another. Jim |
Steve Revill (20) 1361 posts |
Here’s another excellent write-up about HD audio… |
jim lesurf (2082) 1348 posts |
Most of that is excellent. Alas, it also contains a few bloopers due to unspoken assumptions that are doubtful. 1) On average people can hear a range from about 20Hz to 20kHz for test sinewaves. But some people can hear a wider range, say to more like 25kHz. And music isn’t just a single ‘one pure sinewave at a time’. 2) The Fletcher Munsen curves fall into this same trap. They show the relative loudness perception for a test sinewave in an unadapted person. Not the response to more complex time varying music. The missing elephant in the room is the reality that human hearing is inherently non-linear. So what you hear when a complex time varying spectrum of components is played simply isn’t totally described by the unspoken assumtions xiph employs wrt 1 and 2. Note that in double-blind ABX controlled tests Oohashi and others have showed responses that change when ‘ultrasonic’ components are present/absent. By brain scans as well as by people reporting what they percieve. 3) 192k is worse because it produces more unwanted distortion. Again hidden presumptions here. Our ears will do this anyway. Never heard of beats? (No, I don’t mean the headphones! :-) ) And as he says, use decent amplifiers, etc, and this isn’t a problem. Plus which imperfect DACs given 44.1k will generate unwanted garbage above 20k anyway. So avoiding 44.1k doesn’t sold this problem. What avoids it isn’t “not using 192k” but “using decent replay equipment”. Won’t go on, but most of what he says makes good sense. But a few key unreliable assumptions like the above means his argument falls apart as a ‘proof’ that 192k is either needless or worse than 44.1k. FWIW I think 192k is unneccessary in practice for replay as it is overkill. But a rate well above 44.1k makes the job of having a decent ADC and DAC much eaiser when it comes to audio. Its hard to make a good 44.1k ADC/DAC that are flat to above 20k with no problems. Much easier to make 96k ADC/DACs that are. If curious, also have a look at the pages linked here http://www.audiomisc.co.uk/HFN/hearing/index.html :-) Jim |
Chris Dale (2393) 17 posts |
Returning to the subject of the USB Audio software and my Iyonix (RO5.20): Been doing some more tests with !USBRecorder and !IsocRecorder and my Focusrite Scarlett 2i2. As when I first tried last week, I couldn’t get !USBRecorder to run as it couldn’t find the device although I had suitably modified the settings file. I kept doing USB resets and after maybe 5 or 6 tries !USBRecorder (now V0.60) started to work well and continued to work. I had an initial failure until I realised that the 5th line for the maximum recorded Wave file size in the settings file is compulsory, and now all is well. I also tried changing the destination to a folder on the Iyonix hard drive and the maximum time offset time I saw (44100k sample rate) was 5 centiseconds so apparently no problem there. I like the PPMs! !IsoRecorder: This appears to record but the resulting Wave file is no good. Playing it on my Ubuntu machine using Rhythmbox or Totum Movie Player results only in white noise with some sort of very low level, low frequency, very distorted version of the audio added. Maybe there is something wrong with the header info at the start of the file? (Incidentally I noted that Audacity on my Ubuntu machine recognises the 2i2 with no problem, which is useful). I’ll try another post on the ARMini support list later to ask if anyone knows why !USBRecorder won’t run on the ARMini but does run on the Iyonix and ARMiniX. Chris D. |
jim lesurf (2082) 1348 posts |
Glad you like the PPMs. I think they – plus now being able to monitor for a while before starting recording so you can fiddle with the gain controls on the 2i2 – make life much easier. I’d hope you get tiny time offsets for 44.1k recording as the amounts of data that have to be shoveled onto the chosen storage device are much smaller than for 96k. So the 5 cs sounds about right. Keep an eye on it as recording proceeds to see if it either creeps up slowly or suddenly briefly jumps to a value around 100 cs or more, just in case. If it doesn’t, then all should be well. My Iyonix tends to show a slow rise in time offset if I record for some mins at 96k, which makes me suspect its might be missing something, or there is a difference between the computer clock and the one in the 2i2! Sometimes you’ll get a steady few cs shown because the first cycle of recording took a while to get going. The steady value from then on simply is remembering that. However when I asked Jeff D. about Fat32fs giving me problems for recording he made a suggestion I hope to try out that might improve the way data is saved. Know more when I’ve done some experiments.
IIRC Colin’s recorder doesn’t trim the transferred data. That means you’ll be making a 32 bit per sample recording from the 2i2. My recorder trims down to 24 bits per sample. You may find that the versions of Rhythmbox/Totem you’re using get confused by 32bit wave files, particularly if they have a plain wave header. Try using sox to process the files down to 24bit wave and see if they are OK. BTW note that when I tested the new version (0.60) on my Iyonix I had to add a line wimpslot 3000k at the start of the !Run file in the !USBRecorder directory. So if the program won’t start properly, try that. I intend to add this before announcing the new version on c.s.a.announce. Despite being a singletasking program it may need this on versions of RO that aren’t recent. And yes, the new value in the settings file is now vital. In part a safety measure. But if Jeff’s idea works it will become more important. And eventually will be the ‘split’ value for long recordings split over many files. FWIW On Linux I use Audacious set to play directly to the chosen alsa device as 24 bit. That gives bit perfect, sample perfect results. Can’t vouch for Rhythmbox or Totum. The 2i2 follows the audio standards so should work fine with audacity, etc, for any reasonably recent kernel-based distributions. Jim |
Steve Pampling (1551) 7932 posts |
When I was in my teens colour TV’s were rare and walking past houses in the summer I could tell which had colour by listening to the whistle.1 1 Of course also in my later teens I went to various gigs including Deep Purple2 so hearing a whistle is quite easy these days. |
nemo (145) 2437 posts |
I used to be able to hear bats. Either they’ve got a lot quieter or I’ve got old. Either way it’s disappointing. |
Dave Higton (1515) 3404 posts |
Only 15.625 kHz, so not an unusual ability. |
jim lesurf (2082) 1348 posts |
That’s the line whistle IIRC, so may appear for monochrome TV as well as colour, depending on how prone the set is to ‘singing’. Not sure what tone Steve may mean. The colour subcarriers may be a bit high in freqency for him. :-) But maybe he could hear some kind of mix tone between other things? I used to hear line whistle from sets. But I lost that problem long ago! BTW I spotted line whistle on some Proms broadcasts a few years ago that came via the R3 iplayer. http://www.audiomisc.co.uk/BBC/Proms2011/iPlayerRulesAgain.html No-one at the BBC would own up to being the guilty party, but I guess someone is still using a CRT. There are other HF tones at times as well. Maybe lights? I recall Angus McK. finding some singing lights on proms broadcasts decades ago. 8-] Jim |
jim lesurf (2082) 1348 posts |
Just to let people know, I’ve now released a new version of my recorder. As previously, this can be found at http://www.audiomisc.co.uk/software/USBAudioApps.zip along with some other USB audio programs. The page at http://www.audiomisc.co.uk/software/index.html also gives links for finding Colin Granville/Dave Higton’s modules that Note that versions 0.60 and later of !USBRecorder differ significantly from The new versions now show a graphical interface whilst single-tasking to Jim |
Kees Meijer (1777) 39 posts |
I’m playing with the Scarlett 2i2 (thank you Jim for your advise) Time offset when recording to NAS is between 6 and 16 cs – most of the time about 10 cs) |
jim lesurf (2082) 1348 posts |
I’m slightly surprised by that! Here my main SDFS SD card (ARMiniX) tends to give occasional long delays which risk data being missed when I record 96k/24. This may depend on the brand/type/size of SD card, though. So what card type are you using?
Yes. I’m hoping someone (can you hear me ROOL? ;→) will do something about that. It’s crazy that I have over 800 MB of ‘free’ ram, but can’t use a ramdisc bigger than 128MB!
Can you describe more clearly what you mean by the ‘stop’? And what are you using to play the files when you get the problem? Also are you using version 0.61 of my recorder? That holds and display the maximum ‘time offet’ encountered during a recording as otherwise an occasional large offset may pass unnoticed. Interested to hear that you’ve tried 4GB files! I haven’t dared try that! 8-] TBH I’m amazed it works! Indeed, I’m worried that there may be a problem. I’ve used ‘int’ for the type for the payload size, etc, in the program. That should mean I only regard it as ‘safe’ for values up to 2GB. So you have been lucky if the value is OK for the range 2GB to 4GB! I’ve been meaning to put an internal trap in to prevent sizes of 2GB or more, but not got around to it! So please take care. I’d recommend people limit to no more than 1GB. (1) But its good news that recording to a NAS works. I don’t yet have one but planned to try that when I do. BTW I now have a Filecore formatted 120GB SSD which I’m using via a USB adaptor. On tests so far that works fine for recording with time offsets of no more than 7 centisec for 96k/24 stereo using the 2i2. Jim (1) I’m planning sometime to do a version that ‘splits’ at a user-set size like this so you can make multi-GB continuous recordings of arbitrary duration, but the recorder splits it into files for you at that max size, or when you tap a relevant key. |
Kees Meijer (1777) 39 posts |
SD card is 64Gb Sandisk extreme (45mb/sec) btw The 80GB filecore formatted HD on the USB port has not only issues with !USBplay or !USBRecorder. |
jim lesurf (2082) 1348 posts |
OK. I presume that is a problem with your HardDisc4, but I have no idea why it happens. Here replay is fine even for 192k/24 files using either my player or Colin’s IsocPlayer.
That sound OK. 52cs is a bit high, but should be safe.
I’d hope that up to 2GB should work. But I suspect that >=2GB may fail because the value that gets put into the wave file header may be wrong. However I’ve never dared try it. 8-] In normal use I’d recommend values below 2GB as this makes for more managable files anyway, and avoids having files too big for conventional RO Filecore. BTW I cheated in !USBRecorder as I’ve deliberately taken ‘MB’ to mean 1000 × 1000 bytes, not 1024 × 1024, when I do the calculation from the value given by the user. This means that if you give 2048, say, in the file, you get slightly under 2048 MiB and the value going into the header stays in range for an int. 8-) But that may not save you when you give a larger value. I’ve been told that SDFS omits some of the bufferring/DMA that ADFS could provide. But IIUC SCSIFS does bufferring. However I don’t understand the filers at these levels. I can only note that I see that some storage devices/systems can cope OK with a relentless stream of audio, but others pause every now and then and distrupt the flow. The best results I get are from: 1) RAM disc. Fast. But much too limited in size. 2) USB-IDE conventional spinning rust HD formatted Filecore. 3) USB-SATA SSD formatted Filecore. But I suspect this also depends on choosing the actual device with care. (or luck!) Jim |
Kees Meijer (1777) 39 posts |
Found my SCSI filecore formatted problem :) |
jim lesurf (2082) 1348 posts |
Excellent! Do you need to do a Thanks, Jim |
Kees Meijer (1777) 39 posts |
Did a few things: Second time switched off the behringer and restart the Panda output from !USBProbe: Now examine each device in detail [Rates buffer size used/needed = 336] * |
jim lesurf (2082) 1348 posts |
Thanks! :-) From that it looks like it should record at various sample rates and not be limited to 48k rate. Although it may be that the interface chip can, but some other part of the circuit is more limited. Jim |
Kees Meijer (1777) 39 posts |
If I need to modify some of the player/recording programs and test all kinds of things please let me know. Kees |
jim lesurf (2082) 1348 posts |
Thanks. I’ll keep that in mind. :-) FWIW at present I’ve switched to writing a magazine article I need to get done by the end of the coming week, and then trying to do an improved player program. Give it a better user interface, etc. I may also sometime try to produce an automated ‘kick’ program for the USB Audio devices that will give them a reset if they aren’t working correctly. The current requirement to unplug-plug and/or usbreset them is a bit of a pest. Alas, I have no idea why this happens. The devices work without this problem on my Linux systems. Its also annoying that the usbreset command causes the device to become re-numbered. That complicates having a player/recorder program doing this for itself automatically. Jim |
jim lesurf (2082) 1348 posts |
Just to let people know I’ve now released a new version of my !USBPlayer demo program. This differs from earlier versions in various ways: A) It now has a new user interface that looks better than before. Easier to read, etc. And lets you jump replay forward/back whilst playing. B) Now will play a wave file simply by double-clicking on the file, provided the program has been ‘seen’ by the filer. Available as usual from http://www.audiomisc.co.uk/software/index.html in the USB AudioApps collection. Jim |
Chris Dale (2393) 17 posts |
!USBPlayer 0.60: In case it helps: Each day after doing several USB resets as required to get !USBRecorder working with my Iyonix and Focusrite Scarlett 2i2, tried !USBPlayer 0.60. It worked well once or twice and thereafter it fails with a ‘Divide by zero’ error followed by a ‘post mortem’, or more often ‘Open failed!’ followed by ‘play done’. Occasionally it plays for about one second before stopping but more often I can hear only two faint clicks. Doing further USB resets doesn’t help. Chris D. |
jim lesurf (2082) 1348 posts |
Chris: I’ll do some tests with my Iyonix + 2i2 tomorrow if I can. That is RO5.18 here. However I’m puzzled that you need multiple resets and things work “once or twice” then fail. Can you say more about hardware – e.g. using external hubs? Playing from / recording to the Iyo main HD? Also, all 96k/24? All 44-byte header wave (as USBRecorder should produce.)? What does !USBPlayer show on its display when you get problems? When resets don’t help, does USBAudioProbe show non-zero sensible results for the 2i2? Also, take care not to press ‘escape’ rather than ‘Q’. Jim |
jim lesurf (2082) 1348 posts |
OK, I’ve now done some tests with my 2i2 + Iyonix. I can see some of the problems you’ve reported, Colin, but not all of them. If I connect the 2i2 directly to one of the Iyonix’s front USB ports I also find I have to repeatedly do a usbreset or unplug-connect to get it to work. When in a ‘not working’ state it simply returns lists of zeros from my USBAudioProbe. This tells me that the USB Audio module can’t find the device. Since my programs all use that module they then won’t work until the USB Audio module can get sensible results for the USBAudioProbe. However if I connect the 2i2 via an externally powered 4-way USB hub then in general I can get the 2i2 to work after one usbreset or unplug-connect. So there may be some difference in the USB controllers, etc, here. Or maybe this is affected by the Iyonix not providing suitable power. Seems a hardware / USB problem. Using it via a hub I can then record and replay repeatedly with no problems once I get sensible values from USBAudioProbe. Here I recorded to ramdisc to avoid any delays with the storage device. When using something else, keep an eye on the time offset/load values shown by the programs. I didn’t get any of the ‘divide by zero’ results. But what you say makes me wonder if you’re trying to run !USBPLayer by clicking on its icon. That is now not the way to use it. (Apologies, should have added a trap to warn users when they do that. But I relied on saying to read the new !Help file.) To use !USBPLayer just ensure it has been ‘seen’ by the filer or that you’ve run its !Boot file. That then captures the run action of wave files. So to play a wave file, double click on the wave file, not the program. I’m afraid that the problem that requires the usbreset/disconnect-connect is in the hardware / USB module area. So not something I understand or can deal with. Hence a central point here is to always check with !USBAudioProbe first and don’t try to use the player or recorder until that gives sensible non-zero values for the device. Don’t get these problems with other devices like the Dac Magic, so it must be due to something different between those and the devices that seem unwilling to simply connect and work. But not something I can deal with myself, I’m afraid. Hope it is dealt with in due course, though. Jim |
Pages: 1 ... 40 41 42 43 44 45 46 47 48 49 50 51 52