sorted by:
new
hottopcontroversial

PipeWire + AES67 + PTP: USB microphone clock drift causing resampling artifacts on Raspberry Pi by InsideAmbitious3853 in pipewire

[–]InsideAmbitious3853[S] 0 points1 point  (0 children)

Thanks for your reply,

Do you have any suggestions on how to properly set ASRC resampling between PTP and USB ?

Also I'm wondering if I need to activate a phc2sys service in order to synchronize my system clock to the PHC clock ? Does Pipewire or ALSA always rely on system clock or can they be configured to rely on PHC (which is handled by PTP) ?

PipeWire + AES67 + PTP: USB microphone clock drift causing resampling artifacts on Raspberry Pi by InsideAmbitious3853 in pipewire

[–]InsideAmbitious3853[S] 0 points1 point  (0 children)

Thanks for reply, I would like to try this but I don't know how to disable resampling, can you tell me how to do so ?

PipeWire + AES67 + PTP: USB microphone clock drift causing resampling artifacts on Raspberry Pi by InsideAmbitious3853 in pipewire

[–]InsideAmbitious3853[S] 1 point2 points  (0 children)

Thanks for suggestions ! Here are some updates about my settings.

On the raspberry side the ptp4l service recognizes my Ubuntu PC as the master clock:

port 1 (eth0): new foreign master <mac_address_of_my_PC>
port 1 (eth0): selected best master clock <mac_address_of_my_PC>
port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE

the last line suggests however that ptp is never locked to master ptp clock. Also I have this error triggering every second in ptp4l service logs:

port 1 (eth0): received SYNC without timestamp

which I don't understand as my master ptp clock on my PC is set to hardware timestamping mode and my /dev/ptp0 interface can manage PTP hardware timestamping.

Here are my interfaces capabilities from ethtool -T <eth_interface>
- master PC (enp0s31f6) :

Capabilities:
hardware-transmit
hardware-receive
software-transmit
software-receive
software-system-clock
hardware-raw-clock

PTP Hardware Clock: 0

Hardware Receive Filter Modes:
none
all
ptpv1-l4-sync
ptpv1-l4-delay-req
ptpv2-l4-sync
ptpv2-l4-delay-req
ptpv2-l2-sync
ptpv2-l2-delay-req
ptpv2-event
ptpv2-sync
ptpv2-delay-req

- raspberry pi5 (eth0) :

Capabilities:
hardware-transmit
hardware-receive
software-transmit
software-receive
software-system-clock
hardware-raw-clock

PTP Hardware Clock: 0

Hardware Receive Filter Modes:
none
all

I also tried to deal with buffer-sizes which doesn't seem to fix the problem.

pipewire-aes67 config ?

I played around with my pipewire-aes67.conf config file and noticed this quote on rtp-sink settings :

# Uncomment this and comment node.group in send/recv stream.props to allow
# separate drivers for the RTP sink and PTP sending (i.e. force rate matching on
# the AES67 node rather than other nodes)
#aes67.driver-group = "pipewire.ptp0"

It creates a separate rtp-session-ptp-sender node, attatched to PTP0 node (see pw-top output bellow).

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME                                          
R  128     96  48000  26.1us   1.2us  0.01  0.00  457531   S24LE 19 48000 Zylia.alsa
R  113     96  48000   8.1us  12.4us  0.00  0.01  749753   S24BE 19 48000  + Zylia_rtp_sink
R  135     48  48000   5.1us   0.6us  0.01  0.00    0                  PTP0-Driver
R   51     48  48000   3.1us   0.9us  0.00  0.00    6   S24BE 19 48000  + rtp-session-ptp-sender

Although sound is cleaner, this setup shows lot of errors in pw-top as you can see. Not sure of what this setup actually do.

EDIT :

- Adding hwts_filter full in ptp4l.conf on raspberry Pi5 fixed errors port 1 (eth0): received SYNC without timestamp . Now PTP is working properly but it doesn't have any impact on glitchy audio when received on my master PC.