Skip to content

Releases: q-p/SoundPusher

Hide `SoundPusher Audio` when not in use

25 Apr 20:24
@q-p q-p
Compare
Choose a tag to compare

Since the SoundPusher Audio device now doesn't do anything generically useful anymore, we hide it when SoundPusher.app isn't running.

This is done by stuffing the device inside an AudioBox inside the driver that is disabled / not acquired by default. When SoundPusher.app starts up, we enable the box (if we find it), thereby publishing the device.
On exit, we release the box, thereby hiding it again.

(Do note that using the kAudioDevicePropertyIsHidden does not work for this purpose, since it is not settable — irrespective of what the driver says...)

This release replaces 1.5.2, 1.5.3, and 1.5.4 which had minor problems on start-up and were released in quick succession.

v1.5.3 fixes an exception on app start-up when the audio server plugin is missing.
v1.5.4 attempts to fix chains not always restarting on start-up due to the audio device not being visible yet.
v1.5.5 tries the same thing as 1.5.4 but waits a bit longer on start-up.

Simplify Taps & Improve Default Device Restoration

19 Apr 21:57
@q-p q-p
Compare
Choose a tag to compare
  • Simplify tap (and aggregate device) set up
    • Changed the mute behavior to CATapMutedWhenTapped
    • Removed the source device from the aggregate device
    • Removed setting drift compensation for the tap (since it's only the tap there)
    • Reordered the initialization order of the chain a bit, so the tap isn't interjected between setting up the output and source device
  • Default device restoration now always happens

Use Core Audio Taps for recording

18 Apr 19:34
@q-p q-p
Compare
Choose a tag to compare

Subtitle: Trade a big orange dot for a small purple one

This release requires macOS 14.2 "Sonoma"

Instead of requiring an audio device that mirrors the audio data it
receives back to its input (looking like a microphone), we now use a
Core Audio tap on a private aggregate device to listen in on the output
it receives.

That lets us work with just "system audio recording" permissions. These
can be found in:
System Settings -> Privacy & Security -> Screen & System Audio Recording

Microphone access is no longer needed unless the output device that
is tapped also has inputs.

SoundPusherAudio has lost its ability loopback the audio that it receives
to its input, since it no longer provide any input streams.

Adjust Rear Upmix and Fix Installer

17 Apr 16:17
@q-p q-p
Compare
Choose a tag to compare
  • Adjusts the rear upmix to be slightly louder (and closer to what DPLii does — I hope). You can revert to the old version via defaults write de.maven.SoundPusher UpmixDPLiiRear -bool NO (after which you need to restart the app).
  • Fixes an error in the installer (from attempting to restart coreaudiod) on macOS 14.4 and up.

Note: I am unlikely to move to newer FFMPEG versions as I am not able to encode the audio without memory allocations using the new API.

Rework SoundPusherAudio's Timing

19 Feb 13:51
@q-p q-p
Compare
Choose a tag to compare

This completely changes the way reading and writing in the audio device is synchronized.

Let's hope this is a bit more robust... ;)

FFmpeg 5.0 + adjustable IOCycleSafetyFactor

16 Mar 19:44
@q-p q-p
Compare
Choose a tag to compare

This release updates to the FFmpeg 5.0 API and jumps through a lot of hoops to avoid memory allocations in audio-threads as the new FFmpeg APIs allocate memory left, right, and center (e.g. AVBufferRef).

It also changes the default for the safety-factor used for the measurement of the IOCycle adjustment from 4 to 8. It can also be manually set via defaults write de.maven.SoundPusher SafetyFactor -float <value>. Any value less than 1 disables IOCycle adjustment completely (but results in more latency). If you encounter drop-outs, you can try to set this to a higher value, but hopefully the new default works for most systems.

Fixes #24 (not sure whether #23 is the same root cause.)

Apple Silicon support

19 Dec 15:50
@q-p q-p
Compare
Choose a tag to compare

This release is natively compiled for Apple Silicon (including the FFmpeg AC3 encoder).

None of the available Apple Silicon Macs have a built-in digital (optical) output, so you will need a compatible audio interface. I've been using a "HiFimeDIY UAE23 USB DAC (ESS Sabre ES9023+Savitech SA9023)" and it's been working fine for me.

Support any (compatible) input device

06 Jun 10:02
@q-p q-p
Compare
Choose a tag to compare

This release no longer hardcodes the SoundPusher Audio device as input device, but can instead use any compatible (6 channels, 48000Hz) device whose sound is encoded and forwarded to the desired output device. This includes Rogue Amoeba's Loopback Audio when configured to provide 6 channels, which was what I was testing with (in addition to SoundPusher Audio).

There's also been improvements to the default device restoration (in particularly when quitting). This should be much more reliable now.

Last but not least: I realized that FFmpeg's "new" send_frame / receive_packet API (which I started using in v1.2.0) has been resulting in memory (re)allocations on the audio thread. That is bad but there seems to be no way (that I could figure out anyhow) to avoid it, so now we're using the old deprecated API again which behaves better in this regard.

Rename LoopbackAudio to SoundPusherAudio

28 May 19:50
@q-p q-p
Compare
Choose a tag to compare

It seems that some users of Rogue Amoeba's Loopback product were also
using SoundPusher and ended up being rather confused. Their product has
a bit more branding, so it's probably easier to rename my device (even
though I was first 😉).

Updated ffmpeg to 4.2.3.

Note that if you mix previous versions of app with current version of
the driver (or vice versa), they will not find each other. You can
safely delete the old
/Library/Audio/Plug-Ins/HAL/LoopbackAudio.driver

Require macOS 10.14 (Mojave)

28 Apr 13:38
@q-p q-p
Compare
Choose a tag to compare

This lets us use AVFoundation's [AVCaptureDevice requestAccessForMediaType:completionHandler:] for querying (and requesting) audio input.

This should be done as soon as the user attempts to start a chain, so they hopefully realize that their action caused this request.