Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipewire-aes67 module compatibility #148

Open
dewiweb opened this issue Dec 5, 2023 · 9 comments
Open

Pipewire-aes67 module compatibility #148

dewiweb opened this issue Dec 5, 2023 · 9 comments

Comments

@dewiweb
Copy link

dewiweb commented Dec 5, 2023

Is someone already test aes67-linux-daemon in convergence with pipewire-aes67 module? I'd like to understand the complementarity of those two projects. At which level each implementation works?

@Play-AV
Copy link

Play-AV commented Dec 6, 2023

^^ I haven't played with Pipewire's AES67 stuff yet. Have you been using it at all? Very curious.

@dsseng
Copy link

dsseng commented Dec 16, 2023

I develop PipeWire AES67 support. It's unrelated to this project and fully independent from the Merging kernel-mode driver

@bondagit
Copy link
Owner

bondagit commented Dec 17, 2023

I develop PipeWire AES67 support. It's unrelated to this project and fully independent from the Merging kernel-mode driver

Just for curiosity, is PTP slave clock sync implemented in PipeWire AES67 module ? what audio clock is used for the streams ?

@dsseng
Copy link

dsseng commented Dec 17, 2023

No, we currently rely on ptp4l (typically) syncing the clock. Reimplementing all that code doesn't seem feasible, also because PipeWire runs as a user unit and cannot access port 319/320 and adjust clocks. We use PHC (/dev/ptp*) clocks to adjust both stream position and rate of activation (this also makes applications using the AES67 sink follow the GM clock).

Do you know if ptp4l has an API to get the current GM identity (MAC)? We currently do this by using pmc and then manually filling out the field (or copying it from other devices' SDP data)

@cloudcastsystemsau
Copy link

@dsseng how do you change the rate of sending rtp packets? Do you have 1ms timer, how does ptp4l influence the rate of sending packets?

@dsseng
Copy link

dsseng commented Apr 29, 2024

They're sent out in accordance to driver clock, which is connected to the PHC device, which is in turn adjusted by ptp4l to match network clock

@JarkkoRx
Copy link

I actually have been testing the functionality of aes67-linux-daemon and pipewire-aes67 simultaneously (obviously on different systems), and, nothing surprising here, interoperability works as expected. I actually do hope that @bondagit and pipewire-aes67 team would collaborate in some way, just to make one perfect open source solution for AES67. Let's hope Windows would also get something from this front :)

@dsseng
Copy link

dsseng commented Jul 12, 2024

Happy to know that! Well, having AES67 now might be a good reason to poke around getting PW on other platforms if possible

@Play-AV
Copy link

Play-AV commented Jul 13, 2024

I actually have been testing the functionality of aes67-linux-daemon and pipewire-aes67 simultaneously (obviously on different systems), and, nothing surprising here, interoperability works as expected. I actually do hope that @bondagit and pipewire-aes67 team would collaborate in some way, just to make one perfect open source solution for AES67. Let's hope Windows would also get something from this front :)

Windows works well for me.
You can run Audinate's Dante VSC or roll your own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants