USB Audio Clicking Noise

No, I haven't, since I could clearly identify that the crackling which one hears in the example in post #13 does not come from the ~17Hz sample rate difference. As I wrote, the latter can be only heard via VLC (which doesn't adapt its sample rate and insists on 44100Hz) and it gives (in addition to the crackling) a much more louder and ugly interference. Since I work a lot with electronic music instruments which produce their sound through RF interference like Theremins and Ondes Martenot, I have well trained ears for almost everything which can go wrong with audio. But that crackling noise is something new, so I will have to dive into.
 
I'll try to reproduce this, when I'm back home - There is a way to increase the USB buffers - don't remember the exact way but I'm sure we can find it... wonder if that helps..
 
I can confirm that it's not a sample rate problem because that sounds much different from the crackling in post #13, as I could confirm with VLC which can't adapt the sample rate, not even slightly.

Since the crackling is rather aleatoric, not a regular pattern, I'm also not sure if that can be a buffer issue. I won't play/guess wildly around with that before I haven't a precise diagnose.
 
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveformSine   sine1;          //xy=493,348
AudioOutputI2S           i2s1;           //xy=713,128
AudioOutputUSB           usb1;           //xy=806,345
AudioConnection          patchCord1(sine1, 0, usb1, 0);
AudioConnection          patchCord2(sine1, 0, usb1, 1);
AudioConnection          patchCord3(sine1, 0, i2s1, 0);
// GUItool: end automatically generated code

#include <AudioTiming.h>
AudioTiming audiotiming;

void setup() {

AudioMemory(20);
audiotiming.init();
audiotiming.begin();
audiotiming.setI2S_freq(44100); //<- this changes something

sine1.frequency(2000);
sine1.amplitude(0.2);

}

void loop() {}
https://github.com/FrankBoesing/AudioTiming

Well, sorry that I tried to change the frequency ;)
The above sketch shows some effect - on my computer (WIN10), the first seconds of sound are perfect. Then, the crackling begins.
If I comment out audiotiming.setI2S_freq(44100); the crackling starts immediately.

Increasing the Audio USB Buffers did not change anything. Wonder what it is.. we'll find it :)
 
It has nothing todo with the Teeny-Reset when uploading a new sketch - If you disable/enable the device in Windows, it's the same effect with 44100 - first seconds are perfect, then, it begins..
Sounds to me like a driver problem(?)
Can someone try it with Windows XP? I wonder if Microsh*t has updated their drivers.. because... that's a "new" bug. I've used it in the past, last year or even before, and it worked.
 
I have probably found something... The AudioOutputUSB::update(void) function in usb_audio.cpp has some code to execute in case of buffer overruns from line 295 (i.e. if the computer is consuming the audio too slowly). I added a line to toggle the LED (don't forget to set pinMode in setup()!) and it goes on and off, so there is obviously something wrong with the buffering, since my brand new macBook Pro does consume USB audio from other sources (24bit/96kHz) without problems.
Code:
    } else {
          // buffer overrun - PC is consuming too slowly
          GPIOC_PTOR = (1<<5); // <=== I added this line and so the LED indicates that it happens all the time and flickering seems to be synchronous to the clicking!!!
          audio_block_t *discard1 = left_1st;
          left_1st = left_2nd;
          left_2nd = left;
          audio_block_t *discard2 = right_1st;
          right_1st = right_2nd;
          right_2nd = right;
          offset_1st = 0; // TODO: discard part of this data?
          //serial_print("*");
          release(discard1);
          release(discard2);
    }

It's not only on Win10, it's on macOS and Ubuntu Linux, too. So, most probably not a driver thing.
 
Yes, I can confirm this. Indeed, it is synchronous - with 44.100, the blinking begins _exactly_ when the crackling starts, after a few seconds. Good find :)
 
Next step. I commented out the buffer offset adjustment after a buffer fail (Paul's famous TODO) as below, and now, the cracks are almost away, I have only one big click every ~14 seconds.
Code:
    } else {
          // buffer overrun - PC is consuming too slowly
          GPIOC_PTOR = (1<<5); // <=== I added this line and so the LED indicates that it happens all the time and flickering seems to be synchronous to the clicking!!!
          audio_block_t *discard1 = left_1st;
          left_1st = left_2nd;
          left_2nd = left;
          audio_block_t *discard2 = right_1st;
          right_1st = right_2nd;
          right_2nd = right;
          //offset_1st = 0; // TODO: discard part of this data? <=== Commented this out to greatly reduce the clicks
          //serial_print("*");
          release(discard1);
          release(discard2);
    }

Now I'll try again with 44100...

Edit: aaaaargh, can't yet, my audio library has no audiotiming object...
 
Download link above :)

a Tip: You don't need to hear annyoing sound or loud sinewaves if you use sine1.frequency(20000); :) ahh.. this silence is fantastic.. no beep:) but still crackling...
 
44100 is somewhat different, but it's still there.

edit: but it does not blink(?)
have you tried #define MACOSX_ADAPTIVE_LIMIT (line 40?)

Ok, i take a break. Tomorrow is another day. Good night.

P:S: We should try an old Teensyduino version ! I'm sure this is a new issue..
 
Last edited:
Yeah, at age 54, I don't hear the 20000Hz... But the problem persists. Since I can't believe that we get buffer overruns with the most modern hardware and different most modern OS, I think the problem is somewhere in the transmit callback function or on the USB transport configuration level. But there, I have zero competence, so I'm probably out of the game for the moment.
 
Last thing before I leave: I did some additional checks and I found that commenting out the offset_1st = 0; line eliminated the cracks but it is directly responsible for the huge squeaks every 14 seconds. These are buffer underruns as I could find by putting my LED diag line into the transmit_callback function.

So, setting the offset to 0 in case of an overrun produces continuous crackling, not setting it to 0 in case of an overrun produces a loud underrun every 14seconds.
 
Hm, as this is an important issue, Paul should take a look, really.
I'm out, too. I know why I don't like USB-Code.
 
I have this thread on my list of stuff to investigate.

T4 is consuming almost all my dev time right now. Might be a few weeks or more until I look at this.
 
Thanks Paul, I hope it will be fast :)

I have test with Arduino 1.6.9 and Teensyduino 1.30, and exactly the same problem ....
 
Thanks for all the replies, I started this thread probably a week ago, I was away for a few days and now I am back and see we seem to be going around in circles with more complicated sketches. which are likely to add to the problem rather than help solve it.
My first sketch was a very basic sketch generating a sine wave and outputting it to Teensy USB, and plugging it into a PC and listening to it directly or recording it in Audacity and playing it back over the PC speakers and also zoomin in to the waveform on Audacity to see if I was getting any glitches. I also found I had to have DAC connected to keep the USB audio going. You can edit the sketch for a continuous tone rather than a sweep.
This tests USB output on its own and I get clicks, I have tried it on Win XP, Win 10, LUBUNTU 18.04, all with same results. I get clicks but the audio waveform looks perfect with no glitches

My problem is I have no other way of listening to the USB audio other than using a PC because I have no other USB audio devices, because I cannot get any USB Audio speakers or USB Audio to line adaptors in the local shops, but I will now buy some online just to try them, It will take a few days to get them.

I was hoping maybe someone would have USB speaker or adapter to try.????

Question....Is USB not popular for Audio or has it just not been widely developed yet..??? My only reason for wanting to try it is that only one lead needed to carry power and Audio


Code:
#include <Audio.h>
#include <Wire.h>
//#include <SPI.h>
//#include <SD.h>
//#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveformSine   sine1;          //xy=244,163
AudioOutputUSB           usb1;           //xy=557,160
AudioConnection          patchCord1(sine1, 0, usb1, 0);
AudioConnection          patchCord2(sine1, 0, usb1, 1);
// GUItool: end automatically generated code

AudioOutputAnalog     dac1;
AudioConnection          patchCord3(sine1, 0, dac1, 0);

 int freq = 2000;
  
void setup() {
  // put your setup code here, to run once:

sine1.frequency(freq);
sine1.amplitude(0.4);

AudioMemory(80);
//delay(500);

}

void loop() {
  // put your main code here, to run repeatedly:
//freq = freq + 100;
//sine1.frequency(freq);
//while(1);
//delay(500);
//if (freq >= 2000) freq = 100;
}
 
I tried it just now, but could not reproduce the problem.

I ran it with Ubuntu 18.04.1, Linux kernel 4.15.0-38-generic.

To test, I uploaded the code from msg #44 to a Teensy 3.6. I set Tools > USB Type to Audio. All other settings were at defaults.

Then I opened Audacity and clicked the red record button. It defaulted to recording from the Teensy, probably because it was the most recently added USB audio device. I didn't click *anything* else in Audacity, only the red record button. I let it record about 10 seconds before I clicked the stop button.

When I clicked play, I got no sound. My guess is it was defaulting to try playing through the Teensy.

I unplugged the Teensy and clicked play again. I did not click *anything* else in Audacity. This time, with the Teensy gone, it played through my computer's speakers. I heard the shrill sound of the 2 kHz sine wave. Other than the start and stop, I do not hear any clicking, popping or other strange sounds. It's just a continuous unpleasant-to-listen high pitch sine wave.

Here's a screenshot.

forum54239.png

Normally I try to document my testing more thoroughly, but I just don't have time to set up a mic in the room and make a good recording and video of the test. Need to get back to work on T4. Annoying as the sine wave is to hear, best I can tell you is I did play the whole ~11 seconds a few times with my speaker volume turned up (a rather unpleasant listening test) and I could not hear any clicks or other odd noises. I did the listening test using Behringer MS40 speakers connected to my PC's optical SPDIF port, so if there were defects in the sound I'm pretty sure I would be able to hear them with this test.
 
I ran one more quick listening test, using this cheap USB audio adaptor and good quality Bose AE2 headphones.

View attachment 15150

Again, Audacity played back the sine wave without any strange clicking noises, except a slight pop at the beginning as the audio output turned on (so easy to hear tiny imperfections with these over-ear headphones). I must admit, I didn't manage to keep the headphones directly on my ears for the entire 11 seconds! It's quite a shrill tone.

Here's what the kernel says in syslog about that no-name USB audio adaptor.

Code:
Nov 13 17:29:10 preston kernel: [1119464.773678] usb 4-13.4: New USB device found, idVendor=0d8c, idProduct=0014
Nov 13 17:29:10 preston kernel: [1119464.773686] usb 4-13.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 13 17:29:10 preston kernel: [1119464.773692] usb 4-13.4: Product: USB Audio Device
Nov 13 17:29:10 preston kernel: [1119464.773696] usb 4-13.4: Manufacturer: C-Media Electronics Inc.

The printing on the top says "Sabrent". I believe it might be this product, but honestly I have no more info about it.
 
Thanks Paul for the tests.
Your #45 test is exactly they type of test I have been doing....as per in my #14.....Its long past bed time here so I will try again tomorrow and post again
Your #46 test on the USB adaptor then eliminates any reaction between PC/Audacity sample rates and teensy sample rates....I will eventually get one and try.
Thanks
 
Paul....... I assume in your quick listening test you Powered Teensy separately by 5V line and plugged USN audio adaptor in to the USB port on Teensy board and listened to audio from the speakers via the lineout of the USB audio adaptor.
I am unable to open the attachment 15150...???

Your kernel syslog.....did you just plug USB audio adaptor into usb port on PC to see what it reads..... not part of the test to test teensy USB audio out.

I will try and do some more refined tests today.....thanks

can you confirm if the 2 tick boxes for audio passthrough in Audacity are ticked in your tests??
 
Here's the image what should have been attachment 15150. Dunno why the forum sometimes gets attachments missing.

DSC_0262_web.jpg

In these 2 quick tests, I run the code you provided in msg #44 on a Teensy 3.6 and used Audacity to record about 10 seconds. Then I plugged the Teensy 3.6 from my PC (actually from a hub connected to my PC) and played the audio back using those Behringer MS40 speakers connected by my motherboard's SPDIF optical port (msg #45) and I played it back through that USB audio adaptor plugged into my PC (actually, the hub connected to my PC) listening with the Bose AE2 headphones.

I did not use the Teensy to listen to the recorded audio.
 
Back
Top