occasional clicks in playback

[Wouter1]

There appear to be lots of problems with recording audio over USB in OSX due to the new T2 security chip

I want to do the acceptance tests https://github.com/Wouter1/EMU-driver/blob/master/Acceptance.md with this new chip now that my new macbook pro has such a chip.

Setup:
MacBook Pro 2019 touchbar, 2.8GHz quad core i7.
macOS Mojave 10.14.6
13', 16GB 2133MHz LPDDR3 RAM,
Iris Plus Graphics 655

Generic HP-Type-C to HDMI 4K Gigabit Ethernet RJ45 Port USB 3.0 Adapter Converter

Both Ethernet and EMU were attached in part of the tests.

Audio rate is set from Reaper. Buffer is set to 512.

I'm not using the computer for other tasks while doing the test. So no keyboard, mouse, trackpad use. No other open apps.

[Wouter1]

Rate	Accepted	Ethernet also on converter
44100	ok	Y
48000	ok	Y
88200	**light static from 1:27-1:50, about 2 per second	Y
88200	**light static from 1:20 to 1:56	N
96000	noise*	Y
96000	ok	N
176400	ok	N
192000	noise*	N

** light static means some clicking/ticking like when you take off your sweater. These are single-sample bad values with extreme out of range values. There seems no data loss (like we would have if data would be missing), just some bad samples as if some bits get flipped.

• noise: low frequency noise part of the time at very low amplitude. Looks more like some noise on a power line than a crack. It is there only part of the time,

[Wouter1]

I read here
https://www.extremetech.com/computing/285971-apples-latest-macs-have-a-serious-usb-audio-problem

a suggested relation with date&time panel. But I could not reproduce that. I got just some system sounds through my recording but no clicks or crackle.

[Wouter1]

Interesting is that I can only reproduce some crackle so far at 88200. But nothing really disturbing at any other rates, just a slightly above normal noise, which I think is not what the fuzz is about.

[Wouter1]

I checked a video here
https://www.youtube.com/channel/UCNNkY4viZz43lB9r_Gcx8Ww
he has a buzz like sound every 10 seconds. Very different from what I have at 88200 Hz

But it does sound similar to the click here (at 2:40)
https://www.youtube.com/watch?v=ZXGyq6EsECk&feature=youtu.be

[Wouter1]

I re-routed the cable mess and checked the connections. I lowered the gain on the line-out and set the gain on the line-in a bit higher. Then I did another run of the tests. Same machine. Ethernet now connected in all tests (because I need it on another machine)

Rate	Accepted
44100	ok
48000	ok
88200	no, one glitch at 7:08
96000	ok
176400	no, static 0:40 - 0:56
192000	ok

[Wouter1]

Conclusion

There are issues with glitches in the recording.
They seem to occur only in the 'odd' rates: 88200, 176400 and sometimes more often than others.

The noise in the previous test seems to be a cabling/amp setting issue and was solved in the 2nd test.

[Wouter1]

I tried to find messages in system.log.

However I ran the acceptance test at 88200Hz for 20 minutes and there was not a single glitch ?? Is the console.app that I need to run to see the system log somehow changing system behaviour?

[Wouter1]

What I can still try is to disable "set Date and Time automatically" in system preferences as suggested here

https://noisegate.com.au/apples-latest-macs-workaround-for-audio-performance-bug/

[Wouter1]

Testing in different configurations now.

Next test, MacBook Pro (Retina, 15-inch, Late 2013) clamshell mode, 2.3 GHz Intel Core i7, 16 GB 1600 MHz DDR3, 10.12.6 (16G29)
Testing with power cord attached. EMU attached to 4K Dell 3214Q attached to hp adapter (HQ-TRE 71025, ethernet+usbc+usb+hdmi ) attached to USBC port of mac. Power adapter is attached to HP adapter. Fresh install of OSX. No additional extensions have been installed, only the EMU ext. Set reaper to request 128byte buffer. Keyboard and mouse also connected to display. OSX 'special effect' sounds of finder are going to laptop speakers, not to EMU (this is different from preivous tests). I had to mess a bit with the finder because it kept forgetting my wallpaper.

note, the HP adapter is this from conrad, Artikelnummer: 1665682 Fabrikantnummer: 38772 EAN: 192018097759
It looks similar to this
MP-UCHDGECH – ALOGIC USB-C MultiPort Adapter with HDMI/USB 3.0/Gigabit Ethernet/USB-C with Power (60W)

Rate	Accepted
44100	ok
48000	2 isolated clicks
48000	ok
48000	3 isolated clicks
88200	ok
88200	ok
176400	ok
96000	ok
192000	ok

88200Hz previously had noise so we tested twice. The 480000 now gave two ticks, so we re-tested twice.

[Wouter1]

As you can see in the zoomed in clicks, these clicks seem not natural. Particularly there is a ripple BEFORE the click. The clicks have identical shape, just reversed. The ripple has a frequency exactly half the sampling frequency.

[Wouter1]

The driver internally is not doing any filtering. So this appears to be some filter deep inside OSX. Another reason to suspect a digital filter here is that there is more pre-ripple than post-ripple, suggesting someone is trying to minimize converter latency. The first suspect to me seems a buffer underrun in a sample rate converter in CoreAudio

[Wouter1]

Next test, MacBook Pro (Retina, 15-inch, Late 2013) clamshell mode, 2.3 GHz Intel Core i7, 16 GB 1600 MHz DDR3, 10.12.6 (16G29)
Testing with power cord attached. EMU attached to Apple USB-C to USB, HDMI, USB-C adapter attached to USBC port of mac. Power adapter mouse and keyboard is attached to HP adapter that is connected but to another USB-C port on the mac. Fresh install of OSX. No additional extensions have been installed, only the EMU ext. Set reaper to request 128byte buffer. Keyboard and mouse also connected to display. OSX 'special effect' sounds of finder are going to laptop speakers, not to EMU (this is different from preivous tests). I had to mess a bit with the finder because it kept forgetting my wallpaper.

Rate	Accepted
48000	ok
88200	heavy clicking (>50) in first minute
96000	ok

[Wouter1]

Next test, MacBook Pro (Retina, 15-inch, Late 2013) laptop mode, 2.3 GHz Intel Core i7, 16 GB 1600 MHz DDR3, 10.12.6 (16G29)
Testing with power cord attached. EMU attached to HP adapter attached to USBC port of mac, with a cable without ferrite coil.
Power adapter connected to another USB-C port on the mac.

Fresh install of OSX. No additional extensions have been installed, only the EMU ext. Set reaper to request 128byte buffer. Keyboard and mouse also connected to display. OSX 'special effect' sounds of finder are going to laptop speakers, not to EMU.

Rate	Accepted
88200	heavy clicking (>50) in first minute

[Wouter1]

Next test, MacBook Pro (Retina, 15-inch, Late 2013) laptop mode, 2.3 GHz Intel Core i7, 16 GB 1600 MHz DDR3, 10.12.6 (16G29)
Testing with power cord attached. EMU attached with a cable without ferrite coil to USB2.0 input 1 of conrad PL-US3H3123 , attached to HP adapter, connected to USBC port of mac.
Power adapter connected to another USB-C port on the mac.

Fresh install of OSX. No additional extensions have been installed, only the EMU ext. Set reaper to request 128byte buffer. Keyboard and mouse also connected to display. OSX 'special effect' sounds of finder are going to laptop speakers, not to EMU.

`tests were done with ethernet disconnected

Rate	Accepted
88200	ok
88200	4 ticks spread out
88200	ok
88200	5 ticks spread out
96000	ok

[Wouter1]

internal speaker output rate changed to 88400Hz, otherwise same as previous

Does not make difference,

Rate	Accepted
48000	5 ticks spread out

[Wouter1]

Doing a test on High sierra with same system

Next test, MacBook Pro (Retina, 15-inch, Late 2013) clamshell mode, 2.3 GHz Intel Core i7, 16 GB 1600 MHz DDR3, 10.13.6 (17G8030)
Testing with power cord attached. EMU attached with a cable without ferrite coil to HP adapter, connected to USBC port of mac.
Power adapter connected to another USB-C port on the mac. Nothing else attached to mac.
NOTE: even attaching the ethernet network cable did cause some ticks

Rate	Accepted
44100	ok
48000	ok
48000	ok
48000	ok
88200	ticks in first 5s. Maybe started too early
88200	ok
96000	8 ticks evenly distributed
96000	ok
96000	ok
176400	ok
192000	ok

[Wouter1]

In high sierra the ticks look different. Still synthetic but now symmetric

[Wouter1]

[Wouter1]

Something seems not to work with the reaper audio settings , if I request 192 kHz from reaper I still get 96kHz, even though the reaper panel shows 192. In the menu, reaper still shows 96

[Wouter1]

The EMU works perfect under sierra on an older MBP so the EMU works perfect.
Assuming high sierra did not do any major modifications in the usb or audio system, this must be something related to the USB-C system

[Wouter1]

Read up a bit on USB3.
From https://en.wikipedia.org/wiki/USB_hub

Note that USB 3.0 hubs do not currently[14][citation needed] perform transaction translation to super-speed for USB 2.0 devices.

Also on the hardware layer there is separate wires for the USB2 data.

So it seems that USB3 is backwards compatible with USB2 by just having a a competely separate hardware layer for USB2.

This makes the problem even weirder as this would suggest all the old USB2 driver software could still be inplace , there would just have to be a separate USB driver added to it?

I need to look at how OSX integrates the two (USB2 and USB3)

[Wouter1]

I can try a few more things

• See if EMU driver logs something when the ticks occur.
• See if something else logs issues, like the "Audio Overload" reported elsewhere. eg https://www.logicprohelp.com/forum/viewtopic.php?t=118978

[Wouter1]

There are no EMU messages when the ticks happen. There were a large number of ticks in the first minute yet not a single EMU message. So the EMU seems happlily receiving and processing.

[Wouter1]

Again had a run at 88.2kHz with large number of ticks in first 30secs. I don't see special messages in the console (no filters are on)

[Wouter1]

There seem 2 possibilities remaining

1. The USB stream delivers bad bits occasionally without reporting.
2. The USB stream works perfect but it gets screwed up later eg in kernel or in reaper

[Wouter1]

Checking if the problem might be in Reaper.

Tested twice with quicktime / Audacity combo, both record and play at 88200. No ticks.

[Wouter1]

Tried to record and play back with audacity directly. It gives a bad effect where the 550Hz beep is truncated in blocks of 0.23s with a 0.005s silence between subsequent blocks. Not sure what is going on

[Wouter1]

Testing same driver in Mojave, with only power cable and EMU attached through the varta adapter.

Rate	Bufsize	Accepted
44100	64	ok
48000	64	ok
88200	64	ok
96000	64	ok
175400	64	5 ticks
192000	64	2 ticks

Ok, this really is the solution. Except that I need to do the proper correction for the offset

The 176 anf 192k rates are now probably failing because these have only 2 input streams while the others have 4. I compute the frame start time now as 1ms before the end time

The start of the frame is 0.5ms before end time in the 192k and 176 k rates.

I can either store the start time, or compute it as part of the StreamInfo.

[Wouter1]

Fixed driver with a 'quick hack': assume frame time 0.5ms if rate>96000 else use 1ms

Strictly we should check the frame time but that needs more work to get the value in the StreamInfo. First we need to see if this is a solution

[Wouter1]

Acceptance tests . Mojave. Clamshell. EMU connected directly with VARTA adapter. Keyboard, mouse and ethernet through HP adapter. Dell3214Q attached through displayport.

Rate	High Sierra Bufsize 64	Mojave bufsize 64	Mojave bufsize 128
44100		ticks at 1:40, ok, ok	ok
48000	-	ok	ok
88200	clicks 7:10	clicks 5:36, clicks 1:30	ok
96000	-	ok	ok
176400	1 click	-	ok
192000	ok, ok	ok	ok

Huh, this driver worked perfect 4 days ago , today not?

[Wouter1]

I notice that the EMU noise level goes UP when I UNPLUG the ethernet network cable ??

[Wouter1]

Tried to change the lowpass filter to use mass 1000 instead of 10000, and damping 36 instead of 100.

Tested in High Sierra, blocksize 64. Works fine for 44.1 and 88.2 but clicks at 192. Maybe I can still try this in Mojave. blocksize 128 might be acceptable at 192

[Wouter1]

Testing driver with subframe sync, hack for frametime (using 1.0ms offset, or 0.5ms if rate>96000), plus a lowpass filter with 1000 mass.

Acceptance tests . Mojave. Clamshell. EMU connected directly with VARTA adapter. Keyboard, mouse and ethernet through HP adapter. Dell3214Q attached through displayport.

Rate	High Sierra Bufsize 64	Mojave bufsize 64	Mojave bufsize 128
44100	ok	-	-
48000	-	-	-
88200	ok	-	-
96000	-	clicking throughout, ok	-
176400	-	clicking around 2:00	ok
192000	clicking throughout	ok	-

[Wouter1]

It seems that with this latest setup, the clicking is more like an all-or-nothing: either it works fine from start to end or you have some clicking from throughout. Also I can do webbrowsing at the same time without influencing the audo (if it doesn't click, it does not start clicking with browser activities).

[Wouter1]

Previously I wrote this

Checking the delay at the various rates

Rate	delta read-write wrap (#bytes
44100	36- 42
48000	0
88200	114
96000	0
176400	228-234
192000	0

But it seems I did not explain this difference fully.

If the first USB framelist would contain larger-than-normal frames, then these sizes would have been stored in the frameSizeQueue and be compensated in the first following write framelist. Apparently that is never happening but I don't understand why not.

[dnadlinger]

Not sure if related, but:

• https://appleinsider.com/articles/19/02/19/pro-audio-glitch-with-t2-equipped-macs-connected-to-usb-20-connections

[Wouter1]

@dnadlinger thanks for the pointer.

I did not yet see this page but there are many pages reporting similarly. For instance it was suggested that unloading timed, turning on/off wifi/network/bluetooth etc etc might help.

I did not find evidence that the USB traffic is now all going through T2. The single hardware diagram of a similar mac does not suggest so either. And if it's not then I don't see why the T2 chip would affect USB.

Somewhere in this thread I also tested unloading the timed and other stuff but could not find a definitely working fix.

[Wouter1]

Maybe the explanation that the delta is never corrected is simple.

The first framelist, the writelist guesses 44, 88, 176 samples in each frame. However some read lists have 1 extra sample. Therefore the writelist is behind some delta.

The second framelist, the write stream uses the 'correct' number, but that just matches the current readlst size. Therefore the initial delta remains.

It is not clear to me how the exact deltas are reached.

At 44.1 we have typically 1/10th of 64 = 6 or 7 sampleframes = 42 bytes delta.

But it's not clear why there is 114 bytes = 19 sampleframes at 88.2

The 228 at 176k is exactly double the delta at 88.2 so it's consistent but still not clear why.

Nevertheless I can plug in these values hard to compensate already in the first sampleframe

[Wouter1]

I was mistaken about the frame sizes, see also the wireshark table I reported already above. Here we can also see the max #framesamples in the frame and #frames per second

I abbreviate #sampleframes as #s and framelist as flist

rate	message in console	max #s / usbframe	#time per flist	E(delta #s/flist)	measured delta #s	measured delta / E = #flists mismatch
44.1 k	maxFrameSize 298 alternateFrameSize 280	46	1ms	6.4	6-7	1
48k	alternateFrameSize is 304	50	1ms	0	0	0
88,2k	maxFrameSize 280 alternateFrameSize 274	45	0.5ms	6.4	19	3
96k	maxFrameSize 304 alternateFrameSize 298	49	0.5ms	0	0	0
176.4k	274	90	0.5ms	12.8	76	6
192k	298?	98	0.5ms	0	0	0

274 bytes at 176k4 has been checked with wireshark.

192k is what I remember: 2 frames per ms, but only 2 instead of 4 channels to compensate

[Wouter1]

The number of #flists that make up the measured mismatch (right column) is weird in all cases.

I would expect that the first TWO frames are a mismatch because the first 2 frames would have the rounded sizes. But there never actually is a 2 frame difference.

Does this match with the number of times we get the message "guessing framesize"?

[Wouter1]

Checking number of times "guessing some queue size" appears when the sound starts (using reaper). Testing both changing the rate in reaper and change rate then start reaper.

rate	number of times (tested multiple times separated by ;)
44.1	131; 73; 132; 72
48	125
88.2	134; 134; 138; 133; 71
96	135
176400	135; 135; 132;
192000	119; 65; 131; 133

[Wouter1]

Usually there appear

• a block of 69 such messages
• some IOAudioStream/IOAudionEngine messages,
• again a separation,
• sometimes:
  • A block of 64 messages and a separation
• a few (5 or so) separate such messages.

[Wouter1]

So we have never more than 2 of these framelists. The idea of 3 or even 6 framelists with extra samples seems out. These extra samples must all be crammed into the first 2 framelists. Can this be the effect of some buffer (of varying size)in the EMU?
Also can we check the details of these first 2 framelists to see if this is correct?

[Wouter1]

At 88200 this are the sizes of first incoming frames

flist 1:
0:274,
1 274,
2:268,
3:268,
4:268,
5:268,
6:268,
7:268,
8:268,
9:268,
10:268,
11:274,
12:268,
13:268,
14:268,
15:268,
16:268,
17:268,
18:268,
19:274,
20:268,
21:268,
22:268,
23:268,
24:274,
25:268,
26:268,
27:268,
28:268,
29:274,
30:268,
31:268,
32:268,
33:268,
34:268,
35:274,
36:268,
37:268,
38:268,
39:268,
40:268,
41:268,
42:268,
43:268,
44:268,
45:274,
46:268,
47:268,
48:268,
49:268,
50:268,
51:268,
52:268,
53:268,
54:268,
55:274,
56:268,
57:268,
58:268,
59:268,
60:268,
61:268,
62:268,
63:268,

[Wouter1]

This is exactly as expected, 44 sframes in each usbframe and 1 sframe extra roughly each 10 frames. There is no excessive number of input.

isochronous out 1,2 all have exactly 44 sframes as expected.

2nd isochronous in also as expected. Nothing excessive.

3rd isochronous out mimics output sizes from isochronous in 1 properly.

[Wouter1]

At 88.2k the output is 44 sframes for the first 2 full framelists. The input has extra sframes: 2 initially plus 6 + 6 = 14 extra. This is still short of the measured 19 but pretty close.

Let's first check the 176.4

[Wouter1]

176k4 first input framelist has 9 usb frames with 274 instead of 268 BYTES. Notice that sframes have 2 samples or 3 bytes now.

That is therefore 90 instead of 88 sframes. Why are we getting 2 sframes extra now instead of 1?

There is roughly 1 such 2 extra sframes every 10 usbframes instead of 1 extra sframe every 5 usbframes. So it DOES match expected 12.8 per framelist on average, but the distribution is nonstandard (officialy the frames can have only 1 excess sframe).

Additionally the 3rd isochronous OUT again has all usbframes set to default 264, so it's not using the just received sizes. Maybe the input is not yet processed when the output is prepared.

The fourth isochronous OUT does use the sizes from the first usbframe input.

So in this case the output lags 3 flists, should be 38.4 sframes rather than 76?

[Wouter1]

Does osx keep the requested distance from the reported head?

[Wouter1]

The logs should show the requested sample offset "sample offset X samples"

[Wouter1]

176k4 first input framelist has 9 usb frames with 274 instead of 268 BYTES. Notice that sframes have 2 samples or 3 bytes now.

I forgot that we also have 4 extra bytes for the windows bug workaround. And each sframe is now 2*3=6 bytes. So there is really 45 instead of 44 sframes which is correct.

[Wouter1]

I got another idea that might be worth trying.
Maybe the buffer is just on the edge of being empty all the time. Then at the slightest delay somewhere, the buffer goes empty, gives a tick, and then it receives just enough data to barely make it to the next batch of data, repeating the ticking loop.

Maybe I can just push some extra zero data into the stream at the start.
This extra data should be in the order of the size of the buffer. It will cause an extra delay of at most 1ms per 44 extra samples. So if we put in say 10 samples this probably is fine

[Wouter1]

Let's try a really simplistic hack in EMUUSBOutputStream - add 1 sample extra to frames

        if (frameSizeQueue->pop(&thisFrameSize) != kIOReturnSuccess) {
            debugIOLog("frameSizeQueue empty, guessing some queue size. May need fix..");
            thisFrameSize = (stockSamplesInFrame+1)  * multFactor ;
        }

[Wouter1]

Testing driver with subframe sync, plus the 'simplistic hack' above.

Acceptance tests . High Sierra and Mojave. Clamshell. EMU connected directly with VARTA adapter. Keyboard, mouse and ethernet through HP adapter. Dell3214Q attached through displayport.

Rate	High Sierra Bufsize 64	Mojave bufsize 64
44100	ok	ok
48000	ok	ok
88200	ok	ok
96000	ok	ok
176400	2 clicks	2 clicks
192000	ok	ok

[Wouter1]

Amazing how simple that fix was given the effort it took to find it