Video series - Setting up Pipewire

[trawglodyte]

I'm learning as I go here. If you're looking for an expert that's not what this is. However, I'm doing this in real time with very inexpensive equipment and there was a marked improvement between Vid 1 and Vid 2 through my speakers which I think is proof of concept. The main points of these videos are as follows.

• Start an /etc/asound.conf and put default setting important to you in it

• per pipewire documentation, uninstall pulseaudio, then install pipewire, pipewire-pulse, pipewire-alsa, and pipewire-jack

• I forgot this in the video, but pipewire also wants you to install wireplumber, if you don't have it already

• make any changes you want to the config files in /usr/share/pipewire, then copy the pipewire folder to /etc

Copying the pipewire folder to /etc seems to be critical in truly making pipewire come alive for you, whether you make any edits to the config or not. Apparently pipewire expects system admins to know this and on your computer you are the system admin. I also think editing the configs is important and can only make everything you do with your apps work better for you. In this case, I think it was changing the low-frequency cutoff default from 150 to 60 that gave me some extra bass response in the second vid over the first. You never really know which of these defaults your apps, players, or websites will use or over-ride, but when you have the configs set, you at least know you are communicating your preferences from the git-go.

vid1 - https://odysee.com/@trawg:3/pipewire:d
vid2 - https://odysee.com/@trawg:3/pipewire2:1
vid3 - https://odysee.com/@trawg:3/pipewire3:e

Some of you will immediately notice a slight high-pitched hum on my audio, and may think "Why would I listen to this guy who can't even get clean audio??" 2-shay. I do address this in pt.3, it might be a capacitor in my card/interface. I'm going to deal with it soon. But, yah, if you want to find someone with great audio, I don't blame you!! lol. My goal is less to be an expert as to collaborate. I couldn't be more thrilled if someone knows more and can teach me!! I've had a heck of a time finding information on these default paramaters, and still have several of them I think are important that I need to learn more about.

[geo_c]

@trawglodyte thanks, watched video #1, inspired me to crack open those configs. I happen to be running a KLV multi-install, which means I can break my system all day long and start over and do it again.

I saw one important config that's been frustrating me, let's see if changing the line:
node.autoconnect = true
to
node.autoconnect = false

eliminates that frustration. Time for a reboot........

Back from the reboot

Well, I broke all the pulse apps. I changed all those config files in viideo #1, and set the buffers from 1024 to 512, which I know this machine can handle, Carla reported 512, musikcube could play mp3's just fine through the jack_mixer. But Parole would just hang and then say the stream is taking too long to load. Also LibreWolf couldn't play video number 2, and every time I tried to start it, it created a new node in Helvum. Could be the auto.connect in the pulse configs. Let's undo things one at a time and see what happens......

still broken So since I have a Psuedo-Full Install in instance0, I just copied the pipewire folder from that into instance3 where I'm experimenting, and ALL Fixed. But I still want to get this running at 512K. I have a feeling that wasn't what broke it. So I'll go a little less shotgun this time around.......

Got Jack Apps running at 512 buffer by default. That was just a matter of changing two lines in the /etc/pipewire/jack.conf. If my jack stuff runs well that way, I'll shoot for 128 next time around.

But I'm going to change one thing at a time so I can tell what's doing what......

I have a little script that starts Carla rack, jack_mixer, and parole all at the same time, and it's very handy for testing these configs. So I changed the buffer to 512 in jack.conf and client.rt.conf and now I think everything but pulse might default to that.

I'm really loving pipewire, using pw-top I can check to see what everything is running at, and no wonder Parole balked at the 512 setting in pulse config (though I'm not totally sure that's what it was) because you can see in terminal below that Parole is running at a buffer of 4320 at 16bit 48K. That's pretty huge. I'll keep tweaking one thing at a time........

[geo_c]

@trawglodyte I think that hum might be coming from your power supply. How good is it? I had a cheap replacement power supply on this laptop for awhile and got that exact same sound.

[trawglodyte]

@geo_c I got rid of the hum. All I had to do was use channel 2 instead of channel 1. You'd think that would have been the first thing I would have tried! lol, nope, but I did get all my connections/pots cleaned and made sure USB and mic cables were good. No power supply, USB powered. I knew I could get dead quiet audio because I had problems several years ago that turned out to be it picking up cell phone noise. Turn off cell and that noise went away. Yah, I guess I have an issue in the pre-amp section of channel 1 on this card. Oh well, I may only need one channel for awhile.

Thanks for the tip on pw-top!! That's going to be very helpful.

Screenshot from 2024-01-30 00-24-03.png (108.63 KiB) Viewed 2198 times

That's really important to me to know Firefox is using float 32-bit.

Honestly all those settings in terms of numbers between 16-8192 I need to do more homework on. I know that's the first thing many people go to the configs for with their latency issues. I'm getting to it, but right now I can't say anything about changing something from 1024 to 512 or whatnot. If you know, tell me!!

[geo_c]

Honestly all those settings in terms of numbers between 16-8192 I need to do more homework on. I know that's the first thing many people go to the configs for with their latency issues. I'm getting to it, but right now I can't say anything about changing something from 1024 to 512 or whatnot. If you know, tell me!!

Well it's how many sample cycles are read before passed through to the pipe, so it's a buffer, which simply means that the more cycles read the longer it takes, but if there's slow cpu scheduling the buffer will prevent clicks and drops in audio. And where that delay in playback comes into play is if you're recording while monitoring a processed signal in realtime, or if you're trying to keep multiple signals in tight sync. So with playing musical instruments while monitoring yourself, this becomes a big deal, but with simple play-back of a video or music it's almost irrelevant, because it simply means with a high buffer rate there will be a half second (500ms) pause or so before the playback starts, but once it starts it's uninterrupted, like this run-on sentence.

The lower I can keep that number on all devices and applications involved the more I can push a key on a keyboard and trigger a sound in the pc and hear it back with no perceived delay. Also important about latency is that Jack audio was able to keep all audio sources sample accurate, meaning they were always in sync to the exact timing of the samples, even with higher latency, but to do so it ran everything at the sample rate and buffer rate of one single hardware device. How pipewire can sync audio running at different buffer rates is a mystery to me, and I'll have to play with it for quite awhile to see how good it really is.

So far I am enjoying pipewire, and I think it will live up to it's promises. If I only use pipewire driven apps and jack apps, so far it's amazing. The pulse apps may be usuable on some level, but have considerations and issues that need to be explored.

[trawglodyte]

Looks like OBS likes F32LE too. I'm probably the only who cares about this, because the converters are good enough to convert formats 100 times, maybe without any perceptible change in quality. Stil, like if I was buying a card and knew OBS, Firefox, etc... wanted F32LE bad enough to over-ride all my defaults I'd probably try to get a card that just gave them F32LE to begin with, and could take their F32LE and send the audio to my speakers without converting to S24LE first.

Screenshot from 2024-01-30 01-38-30.png (196.32 KiB) Viewed 2183 times

I am getting to the buffer size and latency-related settings. There's a bunch of them I'm trying to figure out. Here's most of the ones I need to learn. I'm not sure, but I think these are a little more complicated in that you don't want a global default. Or to change the value every time you see it in configs like I've done up til now. These are interdepndent and I think you may want a different value in one place vs another in the configs.

Code: Select all

#default.clock.quantum-limit = 8192
#default.clock.min-quantum   = 1024
#default.clock.quantum       = 1024
#default.clock.min-quantum   = 24
#default.clock.max-quantum   = 2048
#default.clock.quantum-limit = 8192

#node.latency       = 1024/48000
#node.rate          = 1/48000
#node.quantum       = 1024/48000
#node.lock-quantum  = true
#node.force-quantum = 0
#node.autoconnect   = true

#link.max-buffers            = 24  

#settings.check-quantum      = true
#settings.check-rate         = true

#alsa.period-bytes = 0
#alsa.buffer-bytes = 0
#alsa.volume-method = cubic		# linear, cubic
#alsa.buffer-bytes = 131072

#api.alsa.period-size   = 0
#api.alsa.period-num    = 0
#api.alsa.headroom      = 0
#api.alsa.start-delay   = 0

#pulse.min.req          = 256/48000     # 5ms
#pulse.default.req      = 960/48000     # 20 milliseconds
#pulse.min.frag         = 256/48000     # 5ms
#pulse.default.frag     = 96000/48000   # 2 seconds
#pulse.default.tlength  = 96000/48000   # 2 seconds
#pulse.min.quantum      = 256/48000     # 5ms
#pulse.idle.timeout     = 0 

[geo_c]

I am getting to the buffer size and latency-related settings. There's a bunch of them I'm trying to figure out. Here's most of the ones I need to learn. I'm not sure, but I think these are a little more complicated in that you don't want a global default. Or to change the value every time you see it in configs like I've done up til now. These are interdepndent and I think you may want a different value in one place vs another in the configs.

I changed the buffer rates in jack.conf lines 66-71

Code: Select all

# global properties for all jack clients
jack.properties = {
     node.latency       = 512/48000
     #node.rate          = 1/48000
     node.quantum       = 512/48000
     #node.lock-quantum  = true
     

I left it at default 1024 in pipewire.conf 28-31

Code: Select all

  ## Properties for the DSP configuration.
    #default.clock.rate          = 48000
    #default.clock.allowed-rates = [ 48000 ]
    #default.clock.quantum       = 1024
    

I changed it to 512 in client.conf line 72, but left the filter properties at 1024 in line 69, and changed autoconnect to false (doesn't keep pulse apps from autoconnecting though), not sure what it does:

Code: Select all

filter.properties = {
    #node.latency = 1024/48000
}

stream.properties = {
    node.latency          = 512/48000
    node.autoconnect      = false
    

And did a similar change to client.rt.conf lines 77-83

Code: Select all

filter.properties = {
    #node.latency = 1024/48000
}

stream.properties = {
    node.latency          = 512/48000
    node.autoconnect      = false
    

I have not tested very many applications with these settings yet, though my jack apps are all running at 512, as well as my audio interface, while Parole is still running at 4320, but Parole still works, which is of course IMPORTANT.

I made one change earlier that caused my audio interface to run at 1024, then changed it back to get it back to 512, but I can't remember what I did last night to cause that effect.

[geo_c]

Looks like OBS likes F32LE too. I'm probably the only who cares about this, because the converters are good enough to convert formats 100 times, maybe without any perceptible change in quality. Stil, like if I was buying a card and knew OBS, Firefox, etc... wanted F32LE bad enough to over-ride all my defaults I'd probably try to get a card that just gave them F32LE to begin with, and could take their F32LE and send the audio to my speakers without converting to S24LE first.

You want your software running at 32bit float if it's designed for that, it should NOT be a problem, because that software is resampling to 32 bit float and mixing it in that format internally anyway, which means better quality. When mixed and exported it's converted to whatever format you want the final file to be, which is normally 24bit or 16bit in the case of cd audio, but 24bit seems to be the standard for other quality audio files nowadays. Higher bit rate means more dynamic range and better representation of the upper and lower frequencies.

edit: In addition, the input/output card will normally not use 32F anyway, it is limited by the rate it was built, so my Presonus 24c is 24bit in and out, and whatever it gets from pipewire won't matter to what it converts in it's A/D converters both input and output. Well, it might matter if you config pipewire a certain way that causes it NOT to work at all.

[geo_c]

@geo_c I got rid of the hum. All I had to do was use channel 2 instead of channel

No power supply, USB powered.

And btw I was referring to the laptop power supply. I had a Chinese replacement powering this laptop and was getting extreme noise floor from it, so I bought a proper Dell universal power supply from Staples and it cleared it up.

[trawglodyte]

@geo_c Is "default.clock.min-quantum =" like the audio bitrate? In GUI's I like bump it up to 160 over 128 (I can hear the difference), but sometimes we go lower if we want a small file size. Or is that something different? And what setting, if any, is relative to the audio bitrate?

The other thing I'm trying to figure out is I know in the manual for my soundcard it talks about a block size limit of 2048. But I assume the defaults I'm seeing @ 8192 are fine, it seems to be working fine. Are the ones I'm seeing defaulted to 1024, the ones I need to keep 2048 or less?

[geo_c]

@geo_c Is "default.clock.min-quantum =" like the audio bitrate? In GUI's I like bump it up to 160 over 128 (I can hear the difference), but sometimes we go lower if we want a small file size. Or is that something different? And what setting, if any, is relative to the audio bitrate?

The other thing I'm trying to figure out is I know in the manual for my soundcard it talks about a block size limit of 2048. But I assume the defaults I'm seeing @ 8192 are fine, it seems to be working fine. Are the ones I'm seeing defaulted to 1024, the ones I need to keep 2048 or less?

The reason I left that setting alone is because I think it might interact with the timing (period) of the buffer. There are several settings that come into play that must be balanced, so I can change the node.latency pretty safely and maybe the node.quantum of the clients, but the defaultl.clock quantum seems a bit more crucial to the entire thread processing of the system.

The answer to this question I found on stackoverflow seems pretty sound, and there is some math involved. I'll rephrase it in plain language when I'm sure I comprehend it better: https://stackoverflow.com/questions/240 ... od-in-alsa

Note the above is talking about ALSA configuration, but I reference it to make note of the buffer terminology, and then I can look at how these are configured in pipewire.

[trawglodyte]

@geo_c bwaaahahaaaaa!! yah, the latency math is a bit of a doozy. That's what I was talking about when I said the settings are interdependent on these. Not so easy as just specifying the low-freqency cutoff or audio format you prefer.

[Clarity]

Could you be overlooking or overthinking the hardware communication that goes on when the system starts?

Did you encounter problems that cause the decisions to change initial setup?

IN @geo_c case, he is working with Midi equipment for his music production efforts? As such it may/does require additional tuning for optimal inter-operations. ... I think.

In any event, documenting PC card, The PC CPU, and steps to overcome discomforts could be useful to other members, too.

Just a thought. I am working with defaults without issues, in my case.

[trawglodyte]

@Clarity It's just curiosity really. I had a problem with this soundcard for years where the speakers would burst out in nasty digital noise when I opened certain apps (on Windows too), all I could do was unplug the USB and plug it back in each time. I suppose that is what caused my interest. That's been resolved for some time, now I just want to know how it works. I do think you can improve your overall computing experience (in this case audio) by starting with tailoring the default configs. But it's not for everyone, and it's hard to find good info on how to do it.

One thing I'm working on is a file to place in /etc/asound.conf or ~/.asoundrc that has comments explaining the paramaters and why someone might want to specify a default. Then someone could leave the ones commented out they don't want to tweak and uncomment the ones they do. Pipewire has another location for user-specified defaults and I might be able to make a template file for that too. If I can get that done it would be a lot handier than trying to dig up the info from 1,000 different sources with conflicting and sometimes deprecated info.

[geo_c]

Could you be overlooking or overthinking the hardware communication that goes on when the system starts?

Did you encounter problems that cause the decisions to change initial setup?

IN @geo_c case, he is working with Midi equipment for his music production efforts? As such it may/does require additional tuning for optimal inter-operations. ... I think.

In any event, documenting PC card, The PC CPU, and steps to overcome discomforts could be useful to other members, too.

Just a thought. I am working with defaults without issues, in my case.

For me it's just a matter of controlling things like the buffer rates, and connections, and generally understanding how it all pieces together, and making decisions that affect my ability to use pro audio. It helps me answer questions about using pipewire or pulse or jack. Jack gives a linux audio setup the ability to use a certain collection of effective software with basically a one to one ratio of input quality to recording quality, and pulse gives us the ability to switch audio cards easily and things that everyday users want, but do I need both or either, or just pipewire?

The better I understand the configuration files and how to manipulate them, the easier I can make decisions about developing an effecive setup.

When doing recordings and mixing, just having a setup that apparently works isn't enough. You've got to know that what you put in is what you get. If things are being resampled that's an issue that has be avoided at all costs. If audio is being routed lhrough something like pavucontrol before you hear it on your mixing speakers, that needs to be corrected, I need my digital audio to go straight from the application to the audio device. Looking at the pipewire configs it appears that when certain streams are mixed to an ouput, high and low pass filters are being applied, and it's things of that nature that I need to know are happening. And I may have that wrong, but that's what the settings seem to indicate.

Pipewire-jack library seems to avoid these kinds of issues and allows for a typical pro-audio environment where streams are routed through jack apps started with pw-jack, and that's a big improvement over standard jack because of the added capabilities of pipewire and it's ability to mix other types of applications and devices into the environement.

The truth is I could accomplish 90% of audio tasks from within one pro audio application, Ardour, without pipewire or pulse, but I'd be missing a lot of the creative side of using other applications and streams. Ardour will run fine in any of these environments and the connections can be made internally, similar to what OBS seems to be capable of.

I'm currently having no actual "problems" with my pipewire setup, and by all apearances things are working great. But one of the things that I can do, being privy to such amazing tools as the KL multi-install technique, is I can experiment and break setups at my leisure with no risk to my daily workflow, because I can have 4, 5, 10 versions of the same system. And that means I can tweak configs differently in all 10 and boot back and forth for comparison.

It's one thing to say that developers need to do this or that, but the reality is that a build needs to be used and abused to get to the bottom of what needs to happen next.

So I encourage you to do a multi-instance install and abuse some Kennel Liinux systems and break them real good. That's my learning style, blow up the current setup and figure what's makes it tick, what it's strengths and weaknesses are, and how I might rethink and rebuild it.

That's basically my only real contribution to the KL project. I thoroughly use these systems and see how far I can do certain things with them, and then I share what I found, maybe get advice on fixing an issue, and then share how well it worked.

[Clarity]

@rockedge @bigpup @wizard and others contributed "Largely to the Documentation Area" when any user opens this forum's Main page.

@trawglodyte, I believe your and @geo_c have enormous info that should/would windup in a Document in that very top Section of forum.puppylinux.com

If there is a way to work together on a document, no matter a Setup entry OR a Users entry, that might be the place to create and maintain your experiences. This document could also be an entry within a distro pop-up at pristine-boot time.

Just a thought as many over the coming months will not only use such a doc, but also share usage. This could also serve as a place where more users may join the forum to contribute.

I will help when I can.

[trawglodyte]

If there is a way to work together on a document, no matter a Setup entry OR a Users entry, that might be the place to create and maintain your experiences. This document could also be an entry within a distro pop-up at pristine-boot time.

That's what I'm shooting for, I dunno. Real developers use git so there is version control which allows people to collaborate while keeping track of what's approved, what's experimental and so forth. I'm still just trying to get the config file with clear descriptions of all the paramaters and a brief explanation of how to use it and where to put it for it to work. This should show you what I have in mind, but it needs a lot of work. I will tell you that as bad as this is, it still would have most of the parameters in a file ready to save as ~/.asoundrc and someone could start assigning the values they want. Even if I'm way off on all my comments and instruction that's a hell of a lot more than I had when I started trying to figure it out!!

Code: Select all

## Linux usually defaults to "samplerate" but there are better converters
## put one of the following - samplerate samplerate_medium samplerate_best lavcrate 
## lavcrate_high lavcrate_higher speexrate speexrate_medium speexrate_best
# defaults.pcm.rate_converter = lavcrate_higher

## resample quality - Linux defaults to 4 (1-9) 
# resample.quality = 9

## audio channels, I only do stereo and don't want anything attempting surround
## if I can help it. So I put 2 channels. Don't use this if you want 6 channel or more options.
# audio.channels = 2

## below sets low and high frequency cutoff. Linux usually defaults to 150/15000
## uncomment "channelmix.lfe-cutoff" to extend low frequencies (more bass if your speakers are capable)
## On a surround or multi-channel system this also (somewhat) serves as a crossover for the subwoofer
# channelmix.lfe-cutoff = 60

## uncomment "channelmix.fc-cutoff" to extend high frequencies (you may notice a bit more "sparkle" on your audio)
# channelmix.fc-cutoff = 22000

## channelmix.upmix converts stereo to multi-channel surround formats.
# channelmix.upmix = false
# channelmix.upmix-method = none
# channelmix.disable = true

## audio rate, 44100 and 48000 are both good, but codec libopus only does 48000.
## IMO, libopus will replace AAC as predominent internet audio codec, so may as well do 48000
## IMO, best practice is pick one and stick with it to avoid unnecessary resampling.
# audio.rate = 48000

## Set other allowed rates if you want. I don't for reasons specific to my audio card.
## But you could put something like "44100,32000,96000,192000" any one or combination.
# audio.allowed-rates = [ 44100 96000 ]

## Setting depending on your hardware. Options include ALAW F32BE F32LE F64BE F64LE
## MULAW S16BE S16LE S24BE S24LE S32BE S32LE S8 U16BE U16LE U24BE U24LE U32BE U32LE U8
## to be clear, these optionss are not "better" or "worse", you just want to match your hardware.
## Important for my card, newer cards probably adapt to different formats easier.
# audio.format = S24LE 

## need to work on descriptions, guidance for the following...
#default.clock.quantum-limit = 8192
#default.clock.max-quantum   = 2048
#default.clock.quantum       = 1024
#default.clock.min-quantum   = 24

#node.latency       = 1024/48000
#node.rate          = 1/48000
#node.quantum       = 1024/48000
#node.lock-quantum  = true
#node.force-quantum = 0
#node.autoconnect   = true

#link.max-buffers            = 24  

#settings.check-quantum      = true
#settings.check-rate         = true

#alsa.period-bytes = 0
#alsa.buffer-bytes = 0
#alsa.volume-method = cubic		# linear, cubic
#alsa.buffer-bytes = 131072

#api.alsa.period-size   = 0
#api.alsa.period-num    = 0
#api.alsa.headroom      = 0
#api.alsa.start-delay   = 0

#pulse.min.req          = 256/48000     # 5ms
#pulse.default.req      = 960/48000     # 20 milliseconds
#pulse.min.frag         = 256/48000     # 5ms
#pulse.default.frag     = 96000/48000   # 2 seconds
#pulse.default.tlength  = 96000/48000   # 2 seconds
#pulse.min.quantum      = 256/48000     # 5ms
#pulse.idle.timeout     = 0 

And, yah, if anyone doesn't know. Including something like this in a file ~/.asoundrc on a Linux distro won't change anything unless the user edits it by removing comments and assigning values. It just sits there doing nothing unless someone who's nit-picky about their audio or requires specific defaults decides to use it.

[trawglodyte]

Allright, I found something quite helpful. https://docs.pipewire.org/index.html Good documentation from pipewire. I think for a pipewire system (although an /etc/asound.conf or ~/.asoundrc file still has bearing on default settings) there is another pipewire specific location and perhaps clearer instruction on how to create it..

[geo_c]

Allright, I found something quite helpful. https://docs.pipewire.org/index.html Good documentation from pipewire. I think for a pipewire system (although an /etc/asound.conf or ~/.asoundrc file still has bearing on default settings) there is another pipewire specific location and perhaps clearer instruction on how to create it..

Yes, bookmarking that pipewire documentation is a must. Just having the list of command line programs and options is extremely helpful. You can use pipewire commands to play media from the terminal for instance.

I meant to mention this earlier. My .asoundrc looks like this in /etc, and I'm inclined to leave it and make all the configs in pipewire:

Code: Select all

# Use pulseaudio by default
pcm.!default {
  type pulse
  fallback "sysdefault"
  hint {
    show on
    description "Default ALSA Output (currently PulseAudio Sound Server)"
  }
}

ctl.!default {
  type pulse
  fallback "sysdefault"
}

# vim:set ft=alsaconf:

[geo_c]

@trawglodyte I should probably mention about the above config, that the KLV-airedale-w/pipewire setup appears to be using pulseaudio but in reality pulseaudio is not running.

you can check in a terminal to see if a process is running by using the pidof [PROCESS] command in a terminal:

Code: Select all

root# pidof pulseaudio
root# 

Since that command returns nothing, pulseaudio is not running (though installled)

So KLV-airedale-rt15 with pipewire installed is set up a little unconventionally perhaps. @rockedge and @fredx181 would know more about it.

Code: Select all

rroot# pipewire-pulse -h
pipewire-pulse [options]
  -h, --help                            Show this help
      --version                         Show version
  -c, --config                          Load config (Default pipewire-pulse.conf)
root# pidof pipewire-pulse
1192

[wizard]

@Clarity
@trawglodyte
@geo_c

The "General Information Section" should be for, well, general information for users new to Puppy Linux.

A topic like "Setting Up Pipewire" is a lot more specific and doesn't broadly apply to the majority of Puppy's. It would be a better addition to the "Instructional HOW-TO Section".

wizard

[trawglodyte]

@wizard

I do need to do better about posting in the right place on the forum and not veering off the topic stated in the first post. This is just hard for me because it started as a pretty simple guide making sure you had pipewire, pipewire-pulse, pipewire-alsa, pipewire-jack, and wireplumber. And that you removed pulseaudio. Then copy /usr/share/pipewire to /etc/pipewire.

That's important, and I thought "general information" so that in the future when discussing pipewire I have something to point to to make sure people have done that and we're on the same page.

But yah, these config files are just super interesting to me and now the thread is way off the original intent.

[wizard]

@trawglodyte

You're doing fine with it here. Once it's nailed down and reproducible, you can make a "how-to" to help others.

Thanks
wizard

[Clarity]

The "General Information Section" should be for, well, general information for users new to Puppy Linux.

Agreed!

A topic like "Setting Up Pipewire" is a lot more specific and doesn't broadly apply to the majority of Puppy's. It would be a better addition to the "Instructional HOW-TO Section".

Agreed Again!

What I was thinking is that the common user, whether new or experienced user, need to know this technology is now baked into Puppy Linux. It needs to be 'known' as a feature to new users in a place where the content-understanding is 'front and centered'.

The Linux world of both multimedia and text-formed docs of our past do not apply as much as the Linux world for Multimedia is in a new revolutionary period of maturity. Externally in enjoyment, its the same, but lifting the covers, even a little, in today's distros shows a very different animal provides the benefits that exposes the content people enjoy and need.

It is wonderful to see the enthusiasm forum members are starting 2024 off with shining the light on what's under the hood of modern PUPs/KLs/DOGs. The presence is one-thing...but exposing this presence and its benefit and its use is enormously needed.

It, IMHO, is a radical change. Today's info and tools can make it easy to understand.

That's why I had recommended the General Info section of the forum as a place to publish. User should know of this technology as it is important when/if they decide that want to do something with multimedia in the forum's many distros, which today, have already migrated to (at least the most recent of them) to this maturity.

The HowTo section are important too for both developers (ie setup of Pipewire+Wireplumber+visualization-tool and Wayland) as well as howto for use of these with speakers, cameras, TVs, etc (hardware) and the software which will be used to transport media-info to input-output requirements.

Thus, as I agree with you, I am drawing attention to what I was envisioning as the forum marches forward. Thus, I envision contributions to exist in both of the sections I am mentioning in this post.

Just ideas for now.

[geo_c]

@trawglodyte, a follow up to the buffer latency configs I posted above here: viewtopic.php?p=110574#p110574

I've been running with these buffer rates on a couple different machines, 512 for jack applications and 512 for the client.conf, and so my audio card is reporting running at 512 all the time, and system audio and midi is responsive and stable.

I copied that config to my studio computer which only has 4 processing threads as opposed to 8, being an older i5. It runs well at those settings also.

I'll be looking at more tweaks in the days to come.

[trawglodyte]

@geo_c So, you change node.latency to 512/48000, this makes your latency approx 0.01 seconds? twice as fast as 1024/48000 = 0.02 seconds? And the limit is if you make it too low there won't be enough data to maintain the signal or something? Am I close? Is this also a way to reduce system resource use? Like if I wasn't concerned about latency and changed mine to 2048/48000, just an example. Would this cause more processing load or anything?

BTW - At one time I was involved in some recording sessions and dabbled in multi-track in a very amateurish way. So I do understand why this is important to musicians. I just never bothered to learn the math. I did have Ubuntu Studio for awhile which bragged about a special "low-latency kernel". What would they compile into a kernel to help with latency?

[geo_c]

@geo_c So, you change node.latency to 512/48000, this makes your latency approx 0.01 seconds? twice as fast as 1024/48000 = 0.02 seconds? And the limit is if you make it too low there won't be enough data to maintain the signal or something? Am I close? Is this also a way to reduce system resource use? Like if I wasn't concerned about latency and changed mine to 2048/48000, just an example. Would this cause more processing load or anything?

BTW - At one time I was involved in some recording sessions and dabbled in multi-track in a very amateurish way. So I do understand why this is important to musicians. I just never bothered to learn the math. I did have Ubuntu Studio for awhile which bragged about a special "low-latency kernel". What would they compile into a kernel to help with latency?

Yes the latency is half as long. And that gives quicker response time from the trigger to sound heard when using keyboards and drum controllers, or with hearing back signal processing. I don't think it causes more CPU load necessarily, becaue the buffer doesn't change the amount of data that has to travel through the processor, what it does is create less of a buffer, so if you go too low and the processor can't keep up, the data is lost, as it isn't stored in a buffer, so distortions, drops, pops, and clicks start to occur. 512 isn't astronomically small. I was running jack at something like 32 the other day with just one virtual instrument and no recording software running. The problem comes when a heavier array of software and plugins are running and the system gets slammed. That's why many jack apps can change the jack server buffer rate from the application settings, so it's easy to change it to fit the immediate task.

As far as the kernels go, @rockedge is all about providing us RT kernels, so most of my KLV systems are running RT, KLV-airedale-RT, KLV-bspwm-RT, KLV-spectr-RT. I think KLV-awesome is also RT on my machine. I don't know the ins and outs of RT kernels, but they give certain applications like audio streams priority scheduling in the processor. They've been running great for me, as I don't have anything like a heavy weight audio/media/gaming machine. I just use laptops with normal i5s, i7s, and i8s, with no more than 8GB of ram in any of them.

The combination of real time kernel and lightweight desktops, xfce being the heaviest, but spectr being the lightest, along with pipewire and tweaks is making for some of the best performing audio systems I've personally ever had.

Like I said above, larger latency buffers are not a problem, unless you run your mic through plugins and expect to hear the affected audio back through your headphones. With higher latency it will sound like you have doubler delay applied, because it will be coming back to your ears later. That might sound okay for voice while recording, but isn't what's getting recorded, it's just what you hear through the monitor.