Announcement

Collapse
No announcement yet.

SDL 3.0 Will Now Prefer PipeWire Over PulseAudio

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • shmerl
    replied
    Originally posted by airminer View Post
    AFAIU it looks for pipewire-pulse, because some distros eg. Ubuntu (used to?) configure pipewire for desktop/video streaming, while using pulseaudio for the audio stack.
    Why would Ubuntu have such convoluted set up?

    Leave a comment:


  • Weasel
    replied
    Originally posted by billyswong View Post
    30ms latency is akin to 33.33Hz. In other words, 1.8 frames for 60fps gameplay, and 3.6 frames for 120fps gameplay. Of course many are playing merrily in 30fps, but appreciation of framerate above 60fps of some gamers shows that latency above 10ms matters to them.
    Visual latency is completely different than audio though. And high fps isn't just about reduced latency, it's also about smoothness.

    In principle I agree with you, but I was also being on the high side for casual users you know. 30ms is a bit much even for USB.

    Leave a comment:


  • energyman
    replied
    Originally posted by SilverBird775 View Post
    Real tragedy and a huge loss of audiophile investments is the cancelation of the PCI slots. It seems USB devices appeared out of desperation since USB is the only candidate to survive PCI-E.

    The random reader who wonders how it is even a problem please pass by, enjoy your monthly upgrade routines. Audiophile equipment never gets old or expire, it only wears out. And it's worth half a kingdom plus kidney.
    so explain to me why people making music are actually buying highend usb devices.
    And why usb devices, which do not suffer from the noise inside the case, are 'bad'?
    The usb audiointerface I own blows everything out of the water I ever owned. That includes the soundblaster awe64 gold.

    Also, if you REALLY care about audio - why use garbage like pulse in the first place? Jack for the audiophiles exist. Or go bare alsa. Did that for years, worked great.
    Last edited by energyman; 14 April 2024, 09:28 AM.

    Leave a comment:


  • billyswong
    replied
    Originally posted by Weasel View Post
    For most users, even 30ms latency is enough, you don't need less. Don't talk like everyone is a freaking live musician. Even those who just mix or compose with DAW instead of recording live are exempt from this.
    30ms latency is akin to 33.33Hz. In other words, 1.8 frames for 60fps gameplay, and 3.6 frames for 120fps gameplay. Of course many are playing merrily in 30fps, but appreciation of framerate above 60fps of some gamers shows that latency above 10ms matters to them.

    Looking from another perspective, since sound travel a lot slower than light, milliseconds of extra latency can be achieved just by sitting farther from the speaker. 30ms latency translates to just about 10 metres of extra distance. 10ms means about 3 to 4 metres. (No exact number as speed of sound fluctuates with temperature.) I think this is a better way to describe audio latency, as one can gauge easily how far a speaker needs to be before they perceive uncomfortable latency. From this perspective, if anyone complains total latency below 1ms as not good enough, they are silly. 1ms of latency means about 1 foot of extra distance.

    PCIe latency is in terms of microseconds (µs). Slight fluctuation of ambient temperature is enough to achieve more than that in acoustic. We are talking about latency below the 44.1kHz or 48kHz sample rate of standard audio here.
    Last edited by billyswong; 14 April 2024, 12:50 AM.

    Leave a comment:


  • Weasel
    replied
    Originally posted by SilverBird775 View Post
    Audio is about latency, dear sir, latency. Quality of audio depends on how quick you can react on command signals, data bandwidth is secondary and never an issue. Modern SOC build-in audio have the luxury of the hacked-in-chip dedicated control lines. Those codecs are not your typical PCI-E or USB device. And because you (like most users) are satisfied with the hacked solution you are missing the whole picture. PCI slots have a dedicated control lines, PCI-E does not. PCI delivers commands in real time, PCI-E does not. For an audio (Real-Time processing) the parallel connection is always the only right choice because you cannot catch up the time by a pure bandwidth.
    For most users, even 30ms latency is enough, you don't need less. Don't talk like everyone is a freaking live musician. Even those who just mix or compose with DAW instead of recording live are exempt from this.

    Leave a comment:


  • Weasel
    replied
    Originally posted by mxan View Post
    That's a lot of anger over a nothingburger. Pipewire-pulse might stop being installed by default sometime 10 years in the future but guess what? It's open source. You can just install it yourself and boom, PulseAudio support is back. PulseAudio itself is still maintained too, it had an update just 3 months ago.
    You missed the point. It's not about whether you can bandaid it or not. It's about the developer mindset.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by billyswong View Post

    Your writing shows your concern is in shared channel and lack of real time interrupt, not in serial vs parallel signal transmission. You are attributing your issue to a wrong label.
    *nod* It's not as if the CPU has a dedicated wire to every bit in the RAM chips. At some point, things get shared and it's a question of when it's acceptable to do so.

    I'm reminded of that saying that anyone can build a bridge that stays up, but only an engineer can build a bridge that barely stays up.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by airminer View Post

    AFAIU it looks for pipewire-pulse, because some distros eg. Ubuntu (used to?) configure pipewire for desktop/video streaming, while using pulseaudio for the audio stack.

    If you check for the `pipewire` service, you will switch over to pipewire, even if that's not what the distro intended.

    If `pipewire-pulse` is running, the pulseaudio API is backed by pipewire, so SDL switches over to the native pipewire audio backend, skipping a layer of emulation.

    SDL's default audio backend logic on Linux is now:

    Code:
    If pipewire-pulse:
    Use pipewire API
    elif pulseaudio works:
    Use pulseaudio API
    else:
    Use pipewire API
    That makes sense and the last else condition will take care of the future cases where pipewire is running but pipewire-pulse isn't.

    Leave a comment:


  • billyswong
    replied
    Originally posted by SilverBird775 View Post
    Audio is about latency, dear sir, latency. Quality of audio depends on how quick you can react on command signals, data bandwidth is secondary and never an issue. Modern SOC build-in audio have the luxury of the hacked-in-chip dedicated control lines. Those codecs are not your typical PCI-E or USB device. And because you (like most users) are satisfied with the hacked solution you are missing the whole picture. PCI slots have a dedicated control lines, PCI-E does not. PCI delivers commands in real time, PCI-E does not. For an audio (Real-Time processing) the parallel connection is always the only right choice because you cannot catch up the time by a pure bandwidth.
    Your writing shows your concern is in shared channel and lack of real time interrupt, not in serial vs parallel signal transmission. You are attributing your issue to a wrong label.

    Leave a comment:


  • fallingcats
    replied
    Originally posted by SilverBird775 View Post
    Audio is about latency, dear sir, latency. Quality of audio depends on how quick you can react on command signals, data bandwidth is secondary and never an issue. Modern SOC build-in audio have the luxury of the hacked-in-chip dedicated control lines. Those codecs are not your typical PCI-E or USB device. And because you (like most users) are satisfied with the hacked solution you are missing the whole picture. PCI slots have a dedicated control lines, PCI-E does not. PCI delivers commands in real time, PCI-E does not. For an audio (Real-Time processing) the parallel connection is always the only right choice because you cannot catch up the time by a pure bandwidth.
    According this stack overflow answer [1], 30μs is easily achievable over USB 3.0, but I highly suspect you'll have trouble measuring (much less noticing) the single millisecond USB 2.0 is responsible for.



    [1] https://stackoverflow.com/questions/...b-3-0#26918988

    Leave a comment:

Working...
X