Tracker + and PipeWire - a pipedream?

[barnabasdk]

Have just got my Tracker + and flashed it with the latest firmware. Works fine with a set of headphones.

I am trying to connect it to my laptop via USB-C. When I do, after selecting USB Input + output (you have these backwards btw input should be output and vice versa).

$> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.3 LTS
Release: 24.04
Codename: noble

1. I get two devices in Pipewire. An input and an output. I can then take another output device - say spotify and send the signal not to my sound card but into the Tracker plus input. I can then record the signal. I can then proceed to take the output device and send the signal to a soundcard. I can then listen to Spotify though the plus. Spotify→Tracker→Soundcard. But I cannot hear anything the Tracker itself plays. Just spotify.
2. When I then in the usb menu select “Storage” all of a sudden a new device, that I suspect is the general output appears and patches itself. It is only there for a split second and then dissapears.
3. When “storage” is active the large patch output with individual tracks appears, and I can take the output - track for track - and put it into a soundcard - which then plays the music running on the Tracker +.
4. As soon as I leave “storage” mode - this all goes away again.

I hope you plan to do some work to this in order to get better compability with PipeWire, because today - there really is no reason to install Jackd any more. The functionality is already there by default via PipeWire.

with regards

Nikolaj Hansen

[neilbaldwin]

[nicolai]

Thats interessting, because I don’t remember having any issues on my machine … so lets see:

$ lsb_release -a
LSB Version:    n/a
Distributor ID: Arch
Description:    Arch Linux
Release:	    rolling
Codename:       n/a

My pipewire is at 1.4.8 and I use a 6.16.8-zen Linux kernel. The PT+ has the latest 1.2.0 firmware. And something is broken, because I have to restart pipewire whenever I change the TP+ USB configuration.

• On the first connect, pipewire shows the TP+ midi connections, but no audio connections.
• After restarting pipewire (which runs as a user service: systemctl --user restart pipewire) the audio channels show up. But I need to restart pipewire after changing the TP+ USB configuration.

Ok, that is manageable. But the TP+ Midi configuration seems to be out of order, I did not set anything to send/receive from USB, still it shows up as Midi device.

Regarding TP+ USB Audio configuration:

• Off: only midi channels shown (although did not configure Midi to be USB)
• Input: TP+ shows up in the pipewire graph with 28 channels, no auto connection
• Output: TP+ shows up as audio sink with two channels
• Input + Output: as expected

Playback to my Linux machine seems to be fine, but recording to TP+ results in heavily distorted recordings, something is very wrong here.

[barnabasdk]

If I restart pipewire I get results more in line with yours - not the same though. I think it is a little beside the point - USB is supposed to be hot pluggable and restarting the entire sound system every time a setting changes in a connected device is not really a way forward.

And yes, all the MIDI devices turn up over USB even if they are turned totally of in the MIDI config.

This config allows me to listen to and record via (through) the TP. However there is no way to get just a stereo signal of the music the tracker itself makes. This should be simple since this is already being mixed for the physical line out jack.

With regards to distortion I think you need to watch the level meter in the Sample recorder as you send in signal. Never let it go yellow and definitely not red.

No, I hear it when I replay the recorded wav as well. Just not on the passthrough monitor signal.

[barnabasdk]

I think I solved this.

In order to get better recognition of USB devices and streams I upgraded the Pipewire subsystem of my Linux box to 1.4.9. I do not think this is strictly necessary if you already see the different devices from the Tracker + in linux. After updating I now consistently see the Tracker + when I connect it.

sudo add-apt-repository ppa:savoury1/pipewire
sudo apt update
sudo apt full-upgrade
sudo apt install pipewire-audio pipewire-jack pipewire-pulse pipewire-alsa wireplumber

I still had the same distorted audio after upgrading. And I started looking into what was actually being sent over USB between the devices. pw-top is a good tool.

Turns out the sample rate of what is sent from the Tracker + is sampled in 44.1 kHz. Pipewire defaults to 48 kHz.

Prepare the wireplumber config for a user account

$> mkdir -p ~/.config/pipewire
$> cp /usr/share/pipewire/pipewire.conf ~/.config/pipewire
$> vi ~/.config/pipewire/pipewire.conf

Then change the system to run in 44.1 in place of 48 kHz.

## Properties for the DSP configuration.
    default.clock.rate          = 44100
    #default.clock.allowed-rates = [ 48000 ]
    default.format = "S24LE"  # Or "FLOAT32LE" if you prefer floating-point for DAW routing
    default.clock.quantum       = 256
    default.clock.min-quantum   = 32

Then restart the sound subsystem

$> systemctl --user restart pipewire pipewire-pulse wireplumber

Connect your Tracker + and your laptop. Make sure the tracker sends and recieves usb audio in the config / usb menu. Map the two first channels from the the Tracker plus to a soundcard / usb headset or other on your linux host (using Helvum or qpwgraph).

Now play something on the Tracker +

Verify the signal compability (same sample rate and bitwidth)

$> wpctl status

Find the id of your Tracker+ and the soundcard/device you patched it to.

$> wpctl inspect <id>

Make sure the signal sent matches what is recieved.

This makes my setup work. I know I now default to 44.1 kHz in place of 48 kHz, but my old heavy metal ears can’t tell the difference.

with regards
Nikolaj Hansen

PS. An option to switch samplerate (and bit width?) to what the hardware supports would be a nice update to the Tracker + firmware. Then I could probably just have flipped the sample rate from 44.1 kHz to 48 kHz and it would work.

[barnabasdk]

However ..

Seems the problem in the opposite direction is still not working. So I am talking about sampling output from a source on my workstation → Tracker +. Same distortion as before. Tried with a simple 440 hz test file generated with sox.

Seems that these values are truly hardcoded into the firmware? No detection or negotiation?

This works flawlessly with other hardware (headphones, DAC) I connect.

Could some of the staff maybe (de)bunk this and list said hardcoded values if they exist? I will try to send a signal in the correct encoding to verify.

I am happy to test stuff. I am quite handy around testing / operating systems / compiling etc (senior systems dev.)

with regards

Nikolaj Hansen

[barnabasdk]

More updates.

Forget about the changes to pipewire / the pipewire.conf “hack” I did to make this work. Leave it as is for your chosen distro and version of pipewire.

Use wireplumber, a “plumber” daemon you can have running on top of your pipewire service, that does the “plumbing” automagically between devices you connect.

Well, automagically if you do some fiddeling. It is linux after all.

1. remove the .config/pipewire/pipewire.conf

2. configure wireplumber to do the job.

2.1) Ensure wireplumber is installed. I really cannot remember if I did this by hand.

$> sudo apt install wireplumber

2.2) create a per user config folder and file.

$> mkdir -p .config/wireplumber/main.lua.d
$> touch .config/wireplumber/main.lua.d/50-tracker-plus.lua

2.3) Update the contents of your wireplumber config to reflect your hardware setup. Mine look like this.

table.insert(alsa_monitor.rules, {
  matches = {
    {
      { "device.name", "alsa_card.usb-Polyend_Tracker_Plus-00" },  -- Matches the Tracker card for broader coverage
      { "node.name", "alsa_input.usb-Polyend_Tracker_Plus-00.multichannel-input" },  -- Input for sampling from PC
      { "node.name", "alsa_output.usb-Polyend_Tracker_Plus-00.analog-stereo" },  -- Output for multi-channel stems to PC
    },
  },
  apply_properties = {
    ["audio.rate"] = 44100,           -- Lock to 44.1 kHz
    ["audio.format"] = "S24_LE",      -- 24-bit signed little-endian
    ["api.alsa.period-size"] = 512,   -- Stable buffer
    ["api.alsa.headroom"] = 16384,    -- Increased for input distortion fix
    ["api.alsa.disable-tsched"] = true,  -- Disable timestamp scheduling for USB timing
    ["session.suspend-timeout-seconds"] = 0,  -- Prevent USB suspend
    ["priority.driver"] = 2000,       -- High priority to prefer Tracker for audio/MIDI
    ["log.level"] = 3                 -- Enable debug logging for this device (temporary for troubleshooting)
  },
})

2.4) restart wireplumber

$> systemctl --user restart wireplumber

Playback works as intended - even via a usb hub.

Sampling of the input signal does not though. I setup a mapping in pipewire that sent tracker->gnome->soundcard. This works. To monitor it at the same time I sent the gnomesound->tracker.input. if you do this you can listen to what the tracker plays (which works) in via your workstation and your speakers and at the same time use the monitor part of the sampler to check the input.

When you ask the tracker to montior its own output the signal is still distorted / garbled.

You can also test with a generated test file via sox.

1. Generate a test signal

$> sox -n -r 44100 -c 2 -b 24 test_signal_441.wav synth 10 sine 440 vol 0.5

2. Send the test signal

$> pw-play --target "alsa_output.usb-Polyend_Tracker_Plus-00.analog-stereo" test_signal_441.wav

[barnabasdk]

BUG REPORT: Polyend Tracker Plus — USB Audio Sampling Produces Garbled Output on Linux

Reporter: NikolajHansen (also confirmed by user “nicolai” on this forum)
Firmware: bcdDevice 1.01
Host OS (broken): Ubuntu 24.04, kernel 6.17.0-20-generic, PipeWire 1.0.5
Host OS (working): Windows (USB audio playback and general use confirmed working)
Hardware: ThinkPad X1 Carbon Gen 9

SUMMARY

When sampling audio via USB on Linux, the recorded sample plays back heavily
garbled/distorted. The same workflow on Windows produces clean recordings.
Extensive testing has isolated the corruption to inside the Tracker itself —
Linux sends a mathematically perfect audio signal, but the Tracker’s recorded
sample is corrupted.

REPRODUCTION STEPS

1. Connect Tracker Plus via USB to a Linux host running PipeWire
2. Route audio to the Tracker’s USB sink (e.g. Spotify, or a test tone)
3. Use the Tracker’s sampling function to record from USB input
4. Play back the recorded sample on the Tracker
5. Result: heavily distorted, “bitcrusher”-like audio — correct pitch but
   waveform is corrupted with large discontinuities

WHAT THE DISTORTION SOUNDS LIKE

• A 440Hz tone is still recognisable at the correct pitch
• But it sounds like it has been passed through a bitcrusher / hard distortion
• A drum loop also sounds garbled (not just sine waves)
• The distortion is present on the Tracker’s own headphone output and also
  when the sample is played back out via USB multichannel to a DAC

TECHNICAL ANALYSIS

We captured and analysed the raw PCM data at both ends of the signal chain.

INPUT to Tracker (what Linux sends via USB):

• Format: S16LE, 44100Hz, stereo
• Generated a 440Hz sine wave at -18dBFS
• Analysis of 3 seconds: 0 glitches, max step between consecutive
  samples = 264 (of 32767 full scale), peak amplitude = 4126 — exactly
  the mathematically correct value for -18dBFS
• Conclusion: Linux is sending a PERFECT, clean audio signal

OUTPUT from Tracker (sampled audio played back via USB multichannel):

• Captured using pw-record from the Tracker’s 28-channel multichannel
  USB output, then analysed with Python
• Result: 10–23 large step discontinuities per 23ms block
• Step sizes: 1000–2000 sample units (30–60% of full scale)
• These discontinuities cause the “bitcrusher” sound
• Conclusion: the Tracker has received clean audio but is playing back
  corrupted data

THINGS RULED OUT

• Clipping/overload: tested at -18dBFS and -30dBFS, both garbled
• PipeWire xruns: pw-top shows ERR=0 on the Tracker sink node during playback
• Wrong format: confirmed S16LE 44100Hz matches the Tracker’s USB descriptor
• Linux→DAC path: Tracker multichannel playback (drum loops etc.) through
  Linux to a C-Media USB DAC sounds completely clean — only USB-sampled
  content is affected
• PipeWire-specific: the corruption is in data the Tracker itself plays back,
  not in the PipeWire graph
• snd_usb_audio quirks: tried implicit_fb=1 and various modprobe options —
  no effect, as expected given the corruption is downstream of Linux

USB AUDIO DESCRIPTOR (for reference)

Sink (Linux → Tracker): Interface 2, Endpoint 0x03 OUT, ASYNC mode,
explicit sync endpoint 0x83 IN, S16_LE 44100Hz 2ch
Source (Tracker → Linux): Interface 1, Endpoint 0x82 IN, ASYNC,
S16_LE 44100Hz 28ch multichannel

HYPOTHESIS

The Tracker’s USB audio recording implementation appears to have a bug in
how it handles incoming USB packets on Linux. Since Windows works correctly
and Linux sends verified-clean audio, the issue is likely in the Tracker
firmware’s USB receive buffer handling — possibly related to how it processes
the variable packet sizes inherent in ASYNC USB audio (at 44100Hz, USB sends
alternating 5 and 6 samples per 125µs microframe). Windows’s WDM USB driver
may present data to the device differently than Linux’s snd_usb_audio, and
the firmware may have only been validated against Windows behaviour.

OTHER AFFECTED USERS

• “nicolai” on this forum confirmed: “recording to TP+ results in heavily
  distorted recordings” on Arch Linux
• This issue was first reported by NikolajHansen at:
  Tracker + and PipeWire - a pipedream?

REQUEST

Please investigate the Tracker Plus firmware’s USB audio input (sampling)
path for buffer/packet handling issues, particularly with ASYNC USB timing
as presented by Linux hosts. The fix should be in firmware, not the host
driver, as Linux is provably sending correct audio data.

[Dann]

Thanks for the very detailed report @barnabasdk!

Sorry to be the bearer of bad news, but it has been stated in the past that PE devices only support Windows and MacOS officially. Perhaps a Feature Request asking for Linux support would be the best route to go?

Previewing / changing synth patches can lead to corrupted USB Audio

Hi @iv0 , thanks for your comments and questions. I’m sorry you’re having issues with your setup. But unfortunately, we officially don’t support iPads. We only support latest Windows and macOS operating systems with Polyend devices and don’t plan to extend support for iPad in the future.

[ian.hundere]

i’ve ran into this before, too.

it was intermittent for me, i had to restart pw i think to get things back on track.

[barnabasdk]

This is not a Linux issue. It is a audio via USB issue. The error is in your firmware.

USB audio is a standard — it is not a “Linux thing”.

The Tracker exposes a standard USB audio class device. The fact that Windows works is not because Microsoft wrote special Polyend drivers — it is because Windows WDM presents ASYNC USB packets differently enough that the Tracker firmware bug does not trigger. The bug is in the Tracker firmware USB receive buffer handling.

[Dann]

@barnabasdk

This is not a Linux issue. It is a audio via USB issue. The error is in your firmware.

I don’t have a firmware Us Mods are volunteers helping to moderate backstage.

Yeah I wasn’t claiming that it’s a “Linux Thing”. My point is that I wouldn’t anticipate Polyend putting resources into this being it works as expected on the platforms they support. I figured if enough people asked for official support of Linux via a feature request, then there would be more reasoning to seeing this getting fixed.

Just my 2 cents. Again I don’t speak for PE and personally would love to see this get fixed for all of you Linux users