Recordings at 192 kHz very faulty

Hi everybody,

we designed a USB Audio Class 2 interface for recordings on PC (there is no playback function provided in this interface.) This works correctly with several other recording programs (Cubase, TwistedWave, WavePad) but with Audacity we encounter severe problems on two completely different MACs. BTW, except ours, I don’t have any other USB Audio Class 2 signal source.

Up to 96 kHz everything is ok. From 176.4 kHz on, the first signs of the problem appear. At 192 kHz a signal is heavily disturbed as can be seen on this screen shot:
Audacity192kHz.PNG.jpg
The signal is recorded correctly for a couple of ms, then a gap follows where either the signal is replaced by zeros or zeros are inserted, afterwards the recording continues and so on. The upper recorded track shows a 10 Hz (left) and a 100 Hz (right) sine wave and the lower track a 10 Hz (left) and a 10 Hz (right) sine wave. (The “hick up” at approx. 10 ms is not too interesting here, but it does not appear with other recording programs either. I can’t even exclude that it is created by our interface and just “cut off” by the other programs.) The position of the gaps is always identical, i.e., it is not a coincidence that the gaps in these tracks are aligned underneath each other.

To the best of my belief, for several reasons this can only be explained by a bug in Audacity:

  1. All other programs I was able to test did not show any error, even when one signal is recorded synchronously by Audacity and another recording software.
  2. When I switch to a project rate of e.g. 48 kHz the recording is perfect, too. (I assume that Audacity does the down sampling.)
  3. The behavior is identical on two different PCs. Only the sizes of the gaps vary slightly and become sometimes irregular.

I use the newest Audacity 2.1.0. It was installed by the .dmg. One of the PCs I have for tests is a MacBook with OS X 10.7.5 (Lion) and the other is a Lenovo Think Pad with Mavericks (10.9?).

I would be grateful for any help and should we be able to help to correct the (assumed) error, please let us know, we would be glad. Particularly because I was forced to try out several other programs and had to experience why I definitely would want to stay with Audacity.

Best regards

Uwe

Developers don’t hang out on Audacity Forum, so if you ultimately consider this is an Audacity bug you will need to subscribe to then write to the -developers mailing list https://lists.sourceforge.net/lists/listinfo/audacity-devel.

However I can ask you some basic questions first.

Have you tried on Windows (using Parallels or Boot Camp on the MacBook)? That way you can determine if the problem is specific to Mac. A Lenovo ThinkPad running OS X is basically a Hackintosh so I really think you should try that machine on Windows.

Did you follow Apple’s Technical Note TN2274: USB Audio on the Mac?

Have you looked at “Actual Rate” bottom right of Audacity? When recording this should show the rate communicated by the soundcard to Audacity. What rates did you build your device to support?

Have you set your device up in /Applications/Audio MIDI Setup so that the specified sample rate matches with the Audacity project rate?

Does experimenting with “Audio to buffer” in Audacity’s Recording Preferences make any difference?


Gale

Hi Gale,

thanks for your answer. I expected to be “closer to the developers” here but that’s not the first time that one of my expectations turns out to be wrong :slight_smile:

Windows: I am a pure Windos user, I borrowed the MacBook and the HackBook for my tests and it is the fist time I have contact to OS X. Thus the first tests were on Windows. But you may know that Windows supports USB Audio Class 1 only so that 192 kHz is not possible. This is why up to 48 kHz our interface acts as a USB Audio Class 1 interface. All sample rates up to 96 kHz work on all systems (Windows up to 48 kHz) fine. BTW, I believe that I was told that it works on Linux, too, but I’m not sure and I can get no confirmation today. It looks like it is specific only to 1. 176.4 kHz and upwards, 2. Audacity and 3. Mac.

Actual rate: Yes, it was always correct. I wonder why it is not visible in the screenshot.

Apple’s Technical Note TN2274: Indeed, the guy who designed the interface sent me a link to that technote. Without that he possibly wouldn’t have been able to get through with the job.

Project Rate: Yes. The sample Rate of our device cannot be controlled by software (it is an interface between USB and S/PDIF, and you cannot control the sample rate of an independent external digital audio data stream). This is why our interface, when connected, provides only one sample rate. When this sample rate changes, the interface disconnects and re-connects as a different interface. In that case in Audacity you have to rescan and then select the “new” audio device. This, BTW, works fine and must be handled accordingly in other recording programs.

Audio to buffer: I didn’t try that and currently it doesn’t make sense, because:

I experienced a huge and irritating surprise yesterday evening: In order to examine the error more closely, I made a new 192 kHz recording on the MacBook - and it worked! I tried all sorts of things, but it continued to to work perfectly! I changed to the Thinkpad and, except for the very first recording, all others worked, too! I switched between the PCs, rebooted - nothing happened, it simply continued to work!

Is this good news? No, not at all. It indicates that there is an error that may appear or disappear, and that is not better than an error that is constantly occurs. The tests before were made over several days, the error was “stable and reliable”. Nothing was changed - so what do I observe? A pure coincidence that from one day to another it switches from “coincidentally constantly failing” to “coincidentally constantly working” on two PCs? I cannot see any reason!

Uwe

There is no sign yet if Windows 10 will finally add support for USB Audio Class 2.

But USB Audio Class 1 supports up to 96000 Hz as far as I know: The Well-Tempered Computer.


Gale

@Gale: this couldn’t possibly have anything to do with the mis-behavior that You and Bill get on Macs with the experimental scrubbing, could it :question:

Peter

Have you tried running Audio/Midi setup? It’s in Programs/Utilities/

Core Audio treats devices either as “known”, or as “unknown”. A device that supports only one sample rate probably is considered “unknown”.

Logging out and logging back in, restarting the Mac, or running Audio/Midi setup might change this status.

It’s a problem I see with some video digitizers too. Confusing. Some of those old digitizers will only connect if you attach them to the Mac while it’s off and power the device before booting the Mac. The problem is really bad with Firewire 400 devices on a FW800 bus. And with USB 1.1 devices on USB3 ports. And a lot of “USB2” audio devices really are only USB 1.1.

And sometimes, it appears as if all settings are correct in Audio/Midi setup, but reaffirming them still fixes it.

@ Gale:

There is no sign yet if Windows 10 will finally add support for USB Audio Class 2
That’s what the designer of our interface tells me, too.
But USB Audio Class 1 supports up to 96000 Hz as far as I know: The Well-Tempered Computer.
Yes, correct. Meanwhile (since yesterday, to be precise) our interface supports 96kHz/24Bit via USB Audio Class 1, too. And 128/24 or 196/16 via USB Audio Class 1 would also be possible, but in one direction only. Bidirectional only half of it is possible. Windows does support that all. Possibly we will implement it, but we don’t know yet a simple way how to tell the device whether in case of 192 kHz it needs to act as a USB Audio Class 2 device with 24 bits or a USB Audio Class 1 device with 16 bits.

@ Cyrano:

And a lot of “USB2” audio devices really are only USB 1.1.
USB 2.0 is not USB Audio Class 2. In fact, many devices, e.g. µCs, are specified to have a USB 2.0 interface, but actually it is only USB 2.0 compatible and supports Low and Full Speed only. That can be very annoying when you search for a true High Speed USB 2.0 µC.

I tried a lot of things, but nothing in Audio/Midi setup. Could I hope for some kind of hint there? I mean, other Programs record correctly, Audacity also records correctly when I change the project rate to 48 kHz, i.e., downsampling - I cannot imagine that somenthing might be to find in the set up. And of course I often restarted the machines without effect.

I already wrote that the problem I described has vanished a couple of days ago, and it has vanished at the same time on two different OS X machines. It is still absent, thus I cannot make test now, but I have to fear that it will reappear when it becomes a huge problem to correct it.

I test a lot of interfaces. And I just recorded 8 channels of 192 KHz 24 bit audio with Audacity without any problem a few days ago. So I don’t think the problem is with Audacity.

I do know interfaces that report being capable of only one sampling frequency usually do not work immediately with OSX. A lot of stuff is being cached in OSX, preferences included. And Core Audio prefs are set in System Preferences and Audio/Midi setup. I’ve never understood why Apple needs two places for settings when it comes to audio.

Sometimes, everything seems to work, but no audio comes through. And in these rare cases, just launching Audio/Midi setup, changing settings and affirming seems to fix it. Even if settings seem right, I just change something, save and exit.

Core Audio is solid, in general. But it doesn’t handle most things that are not by the book very gracefully. And it throws NO errors to the user. Hec, Since Lion it doesn’t even log much.

Your problem is gone now. Try it if and when it reappears?

I don’t think so, Peter. I have the scrubbing problem in 2.1.1-alpha even at 44100 Hz.

Gale

Yes, in the event of problems you should select the device in Audio MIDI setup, as I suggested in my first reply.

Audio MIDI is the only place you can adjust sample rates and bit depths.

As cyrano said, sometimes simply selecting the device there and closing Audio MIDI can correct problems (though you should take the opportunity to choose the same sample rate that you choose in the DAW). Audacity does seem a little more prone to requiring this than some apps, which could be something to do with the PortAudio audio API we use.

It may well be instructive to see what Audio MIDI Setup reports as your device’s sample rate choice(s) when first connected, and what happens in Audio MIDI Setup when you open a DAW.


Gale

Hi,

it all seems a bit confusing to me and it tells me that I cannot rely that everything always can be expected to work reliably.

Anyway, I recognize that I should point out once more that our interface is different from what you know from other devices and what you obviously assume is the same here:

Our Interface supports only one sample rate. This sample rate is the sample rate of the incoming S/PDIF digital audio data stream, which cannot be influenced by the PC or the interface. In order to handle different incoming sample rates, the interface measures the sample rate and offers it to the system as the only available sample rate. When the sample of the external digital audio data stream is changed and the interface notices that, it disconnects from the USB and reconnects as a different device with the actual sample rate. The sample rate is part of the device’s name, as you can see on the screen shot.

Yes, in the event of problems you should select the device in Audio MIDI setup, as I suggested in my first reply.

This should also answer your first reply. Sorry when I made it not more clear.

It may well be instructive to see what Audio MIDI Setup reports as your device’s sample rate choice(s)

There is nothing that can be set in Audio MIDI Setup for our device. There is only one sample rate, always 24 bit and no volume or other control available. That’ exactly how we want it.

What does “open a DAW” mean? A different digital audio workstation software? I tested the recording functions with Audacity and a few other programs (Cubase, TwistedWave, WavePad). All of them worked from the beginning on, only Audacity needed a couple of days to understand what expect from it :wink:

Uwe

(once again thanking you for your tips ans answers)

Then you have a problem.

There is only one sample rate, always 24 bit and no volume or other control available.

Either you follow “consumer” path, eg 16/48 and Core Audio will resample as needed or you follow the “pro” path in Core Audio. In the latter case, the audio app can set a sample rate and bit-depth. Some DAW’s do, others leave that to Audio/Midi setup.

That’ exactly how we want it.

Why?

It sounds as if you are trying to compensate for Windows’ audio shortcomings by making it worse.

I’ve never seen any audio interface (from the last 20 years) behave like that…

It looks like we misunderstand each other.

UweB wrote:

There is nothing that can be set in Audio MIDI Setup for our device.
Then you have a problem.

Why? That’s what I expect: Nobody and nothing should be able to alter the audio data. And note that I am able to prove that nothing alters the original data. I have a special digital audio generator where I can send precisely defined digatal audio sine waves, e.g., a sine wave of 100% FS with 1/6th of the sample rate with two samples per wave being precisely 0 (values 0.0, +0.5, +0.5, 0.0, -0.5, -0.5 and so on). I cannot not only demonstrate that in Audacity, but als in a hex editor displaying the .wav file. If you want me to, I can send you such a recorded file or post a screenshot here.

What kind of a problem should there be when everything is exactly how I expect and want it?

There is only one sample rate, always 24 bit and no volume or other control available.

Either you follow “consumer” path, eg 16/48 and Core Audio will resample as needed or you follow the “pro” path in Core Audio. In the latter case, the audio app can set a sample rate and bit-depth. Some DAW’s do, others leave that to Audio/Midi setup.

I don’t know about consumer and Pro paths in core audio, maybe there is something that I ought to learn. Anyway, I neither can set the interface’s sample rate nor does anything resample the data (except Audacity, when I want it to).

That’ exactly how we want it.

Why?
It sounds as if you are trying to compensate for Windows’ audio shortcomings by making it worse.
I’ve never seen any audio interface (from the last 20 years) behave like that…

Maybe we are talking about different things. I have no problem with core audio, no problem with Windows, no problem with resamplers or anything (provided that I set the Project Rate in Audacity to the sample rate of the incoming signal and that I also set the export format to the width of the incoming signal). That’s what I learned to be called “bit precise” at some other application. I want that bit precision, I don’t want anything to modiy the data. Do I need to justify that or do I misinterpret your question “Why”?

I don’t use Mac OS X, but I do take more than a passing interest in all discussions on this forum.

If I’ve got this right, you have a unique 24 bit 192 kHz Class 2 USB audio interface, and sometimes it does not work correctly with Audacity, which you believe is due to a bug in Audacity. Is that correct?

What can we do about that? We can’t reproduce the problem and we don’t have access to the device so we have no way of testing or any type of trouble shooting. As the problem appears to be intermittent, can you be sure that it only occurs on Audacity and not in other audio applications, or could it be that you have only observed the problem in Audacity?

I’m aware that there have been problems in the past for Mac OS X recording 24 bit audio date, which makes me wonder, does the problem occur if you set Audacity to record 32-bit float format?

Audacity uses the Portaudio library to capture audio streams from the computer sound system (http://www.portaudio.com/). If you wish to troubleshoot this issue I think a good place to start would be testing whether Portaudio is able reliably capture data from the device. Clearly we can’t do that because we don’t have access to the device, and as you have designed it as a unique device, we obviously don’t even have anything comparable.

I wasn’t asking “why” you designed this device, but the fact remains that even if its sample rate/bit depth choices in Audio MIDI Setup are disabled, selecting the device in Audio MIDI Setup (confirming to the OS that it is default device) sometimes helps Audacity along to record correctly. Why that is the case, I don’t know, but it is more likely to be a PortAudio than Audacity issue.

You have two machines running OS X so you could make parallel recordings comparing Audacity with one or more other DAW’s so you have a longer run of tests to go on. You can also test PortAudio itself without Audacity, as Steve suggests.

Gale

And a quick note on “magically started working” that I haven’t seen pointed out yet:

Operating systems are prone to be set to automatic upgrade these days. If a component on the critical path of your problem was touched, that could explain why it was reliably failing to work, and now it’s reliably working. Proving that can be difficult unless you have a wizard handy on the relevant OS, or virtualization, or both.

Hi everybody,

thanks for your answers. I didn’t respond for a long time because I had to care much for other things.

Steve, yes, it seemed obvious to be a bug in Audacity. Now that I learned about PortAudio, it might have been there, too. But this crazy situation that on two notebooks the bug disappeared contemporary while nothing else has been changed is still continuing. It would have been difficult enough to fix this assumable bug as long as it exists, but without it it is obviously impossible. Except somebody recognizes from the typical effect what might have had happened there.

It definitely did not appear with other applications and it appeared under all circumstances, particularly with 32 bit an float. But it did not appear when the sample rate was high while the project rate was e.g. 48 kHz. Should PortAudio do the down-sampling, one had to have to look there, should Audacity do it, I would expect the effect located in Audacity.

Meanwhile it works one more Mac correct and whatever it was, it feels like it is over. Knock on wood and cross your fingers.

Gale, whenever it reappears, I will have a closer look at Audio MIDI Setup an whether I can influence something there.

Baylink: One of the Notebooks was a Thinkpad and that definitely wasn’t upgraded. But I agree, the effect makes such an upgrade looking obvious.

If the project rate is below the Actual Rate I think you can assume Audacity (more specifically the Libsoxr library) is resampling.

But perhaps you did not do many tests while the problem was still happening, and you can’t rule out fluke cases where the audio was corrupted before it got to Audacity.


Gale

If the bug is in Audacity, then if you use the exact same version of Audacity with the exact same setting, then the bug should reappear.
I presume that you have not updated Audacity since you observed the problem, so as far as Audacity is concerned, the only things that could have changed are the settings.
You can reset the settings in Audacity back to their default values as described here: Audacity Manual

If setting the preferences so that they are exactly as they were when the problem occurred does not reproduce the problem, then logically “something else” must have changed, and logically it is most likely that the “something else” is responsible for the problem.