I am trying to solve my USB audio problems on 2022 M1 MacBook Pro 14" with 16GB RAM/latest Monterey connected to an external DAC via USB which results in irregular audio dropouts. Audio gets muted for about 1 sec after some time using the MacBook and gets more often after some usage, sometimes multiple times in a minute. Internal audio seems to work fine. It is independent on the DAC i use (already tried another one).
Every time audio is muted I get the following error message (with a new timestamp) from CAReportingService (Core Audio) in Console.app:
10:11:30.424212+0200 CAReportingService flushMessagesWithCompletion: flush failed with error '<private>'
I already tried this:
repaired UserPermissions
deleted Audio Plugins
Does anyone have an idea to solve this issue? Is it a hardware or software issue? Thanks
I need help debugging an issue, where an application that uses CoreAudio to mix several input sources into an output screen, experiences crackling in the output stream, but only after the Mac has woken from sleep.
The app was running fine before the Mac went to sleep, and restarting the app fixes the problem.
The application uses a couple of threads to do it's thing, which makes me assume that resource limits are altered by the system for the app, or some buffers used by CoreAudio have changed in size.
Any ideas how to debug that issue?
New Western Digital USB3 apfs+ format Mac OS 10.14.6 TimeMachine after preparing tries to back up 1.07 TB. gets to 3.67gb and fails. No error message
Thanks
Something to do with the Library folders. I'm having a similar outcome. A 20 GB Library folder recovers data to nearly 10TB, well tries to them fails when disk space is exhausted.
I've been developing a Mac OS X application that sends commands continuously over Bluetooth Low Energy to a hardware device. Under Yosemite, the app worked well, with a measured roundtrip latency of 7-12 ms for a command transmission. The command is sent to a custom BLE service in a steady interval of minimum 2 seconds and maximum 0.2 seconds.
Now, I haven't been developing in the last months (the app isn't live yet), then upgraded to El Capitan, and now the same app has a latency of 500-1500 ms, which renders the whole thing absolutely unusable. I am assuming the upgrade to El Capitan is the cause, but I cannot know for sure.
What I checked:
I tested on multiple MacBook Pros running El Capitan, and the latency is always that bad.
The commands have a high latency regardless of the service they're sent to (e.g., the device information service), and it varies a lot with every message sent.
It doesn't matter if I'm using our own application, a third party application named "LightBlue" to send hex strings, or Apple's own "Bluetooth Explorer" Developer Tools (can be downloaded in Developer Resources).
Can anyone hint me to what could cause this, or maybe just tell me that in their environment it all works fine?
To reproduce, connect to any Bluetooth Low Energy capable device with your Mac, and send a hex string of data to it. You'd have to log it somehow or turn on an LED or so, to see if there is significant latency.
Any help is greatly appreciated!
It looks like Connection Parameters used by El Capitan are not what they used to be under Yosemite.
Under OS X, CoreBluetooth decides what Connection Parameters are used for a given device, regardless of the client application. Unfortunately, rules CoreBluetooth relies on to compute the parameters is somewhat opaque and dependent on device (exposed services, DIS, AD). Some rule probably changed in El Capitan.
Some directions you should start looking to:
Apple Bluetooth Accessory Design Guidelines details some rules about connection parameters accepted by apple Centrals,
A latency problem may also be because of a high slaveLatency connection parameter. It helps saving battery life on peripheral, but makes to Central->Peripheral latency somewhat unpredictable. You may reduce the Slave Latency your device accepts,
Sniffer logs or peripheral-side debug would certainly help to understand what parameters actually changed between Yosemite and El Capitan.
In the end Apple DTS helped me solve the problem. They hinted me at the "preferred connection parameters" that were set incorrectly in my firmware.
On earlier versions of Yosemite, those values had no effect (same as on iOS), but since some OS update they are read on Yosemite and El Capitan. Not setting the parameters at all solved the problem.
In my case, the values were set by default:
Connection interval:
minimum 7.5ms,
maximum 50ms
Slave latency: 0ms
Connection supervision timeout: 10000
These values somehow caused the high latency. Here's a screenshot of the settings I had to untick inside the Cypress PSoC Creator 3.3 (I'm using a PSoC 4 BLE).
My question is regarding credit card readers configured in Keyboard mode under OS X. I've noticed that the same reader running under OS X (I'm running 10.9.4, but the same holds true for previous versions) reads out swipe data about twice as fast in Windows 7 as it does on the Mac. For example, if I swipe a card using my MagTek Dynamag reader in to Text Edit (or any app) on the Mac, it can take a good 4-5 seconds to fully output the track data (the track is quite long because it's encrypted). If I run the same swipe using the same computer and reader using my VMWare Fusion Windows 7 virtual machine, the swipe outputs in a text file in about half the time (2-3 seconds). Even with whatever overhead is introduced by running a virtual machine, the output rate is still MUCH faster under Windows.
I originally just thought it was the reader that was slow until I tested it in Windows. Does anyone know what is causing the slower output rate on the Mac? Is it merely a setting or something more involved (such as USB drivers)? Thanks for any help!
I believe this may be a combination of the OS USB drivers and the polling interval setting on the device. Some of the MagTek devices, Dynamag and IPAD included, have a polling interval setting which dictates how quickly the data is ouputted to ensure there is no "skipping" when the data is read.
Reference:
Dynamag Tech Reference - actual page 8
"Programmable USB Interrupt In Endpoint polling interval"
USB HID Swipe Reader - actual page19
"The device has an adjustable endpoint descriptor
polling interval value that can be set to any value in the range of 1ms to 255ms. This property
can be used to speed up or slow down the card data transfer rate."