Announcement

Collapse
No announcement yet.

SDL 3.0 Will Now Prefer PipeWire Over PulseAudio

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

  • #41
    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.
    Same reason the Atari ST was popular for music production. Guaranteed MIDI ports on every unit and a platform where music production applications didn't have to contend with mandatory pre-emptive multitasking.

    Comment


    • #42
      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.
      Please explain how much latency is acceptable to you

      Comment


      • #43
        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

        Comment


        • #44
          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.

          Comment


          • #45
            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.
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #46
              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.

              Comment


              • #47
                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.

                Comment


                • #48
                  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.

                  Comment


                  • #49
                    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.

                    Comment


                    • #50
                      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.

                      Comment

                      Working...
                      X