FWIW I applied those changes to the previous beta driver and Plasma Wayland worked with GBM after I rebuilt kwin from the latest 5.23 git source.

Man you'd think they'd make a new release

Correct version number is `0.30.1'

Update to 0.31

@maikwoehl can you take maintainership of this package? Since it is part of paperwork stack, thanks!

Should WirePlumber be added as a rundep of PipeWire so it's pulled in automatically and just needs to be enabled?

Python syntax highlight in summary.

As an aside Idk if libicu can be enabled for Unicode support is going to be an addition for things like this too while considering another addition to the system base install.

New version again

Haven't quite gotten to it yet, but as far as I can tell the action items are to:

• Rebase
• Package WirePlumber
• Create some kind of announcement (or call-to-testing) somewhere for our PipeWire-using users

In T9977#189494, @SmileYzn wrote:

Yes i´m using it in snap way, It's not a lack of information, but some request to have more native apps that manage sql databases.
I prefer antares sql than beekepper studio.
Thanks 🙏

Yes i´m using it in snap way, It's not a lack of information, but some request to have more native apps that manage sql databases.
I prefer antares sql than beekepper studio.

Solus has snap. You can install it via snap. Incase the staff doesn't add it to the manager.

I double checked everything to see if it was plugged correctly and tried it on windows (just to be sure the unit was working properly by itself).

@TClark77 Hi, I tried again to print on my parents computer and its still failing. I didn't get the "Filter failed" this time thought. The print job simply stopped (on the print job list). If I try restarting the print it stop itself automatically. There's no movement on the physical printer itself.

OK. Sorry for the false alarm, and thank you for helping to clarify the situation.
Since I am the only one currently reporting this issue, I m closing this task. I like Sox-based resampling techniques, so I slowed down the speech synthesizer to avoid sound distortion.
Also, I now see that Pulseaudio in Solus is configured better than in other distributions I ve used. So accept my most sincere apologies.

@DataDrake First of all, thank you so much for taking such things into account. I assumed that it had not even been tested or researched (I mean the Accessibility aspect).
Therefore:

1. I managed to get Espeak-NG to work. I can t describe how I did it, but I restarted Pulseaudio exactly a few times. That is, you are one hundred percent right .;
2. To play the audio stream in raw format, which generates ru_tts, I use the Play utility. Your words made me investigate the problem in more detail. I have found that the endings of words disappear only if the speed exceeds a certain limit. But ... This does not happen if resample-method is used by default.

In any case, there are fears that this will be faced by users who are forced to use voices connected via sd_generic. It would be very good if you could investigate why this is happening. But in general - we can assume that you have overcome me. )
Delays after some of my manipulations disappeared even for ru_tts.

I personally just tested both resamplers on Budgie and could not hear any noticeable latency apart from speech-dispatcher stuttering or delaying to start and that was the case with both. In both cases, once speech-dispatcher "warmed up", the responses were fluid.

I'm gonna step in here and say this has nothing to do with the pulseaudio resampling method. Latency is very low there and we have always had the kind of delay with speech-dispatcher, even with the default speex resampling settings. There may be a reduction in that latency with speex, but it absolutely is still there and not the root-cause in the slightest. I *specifically* researched all of this before we switched resamplers and sox-mq had markedly better quality without sacrificing huge CPU time.

@JoshStrobl This situation has long been known to all, which is why other distributions do not use similar things.
Speech synthesizers do nothing special. They simply generate a sound stream in Raw or Wav format, and either play it with Pulseaudio, or with user-selected means (such as Play from Sox).
When listening to long sound tracks, this effect is invisible, only when playing very short sound events.
Blind users depend on the sound, so they tried to configure some sound in different distributions, and the effect was the same. Therefore, as a rule, stopped on ffmpeg. I know several such blind users.
I still suggest not to lean towards the majority, but to find some reasonable compromise, so that it was good for both blind users and people who see.
This is one hundred percent not a synthesizer, and not my equipment. But I can t show you the sound reproduction spectrogram.
Please note the following detail: finding information on how to set up Pulseaudio is very simple. It will be difficult for a blind user to understand what the problem is. He will try to contact the Orca Mailing List, or the developers of Espeak-NG. Will get the answer that everyone is fine and decide that this Solus somehow destroys the accessibility ...
That is, it is easier for a person who sees to set up Pulseaudio for themselves than for a blind user to find the cause of sound problems.

Needs rebasing.

While I am not strictly opposed to switching to something else besides soxr-mq, you need to provide objective data that proves it is soxr-mq that is specifically causing this and not a symptom of any of your hardware or poor performance in other places like the synthesizer. Otherwise while the cause is noble, it would actively diminish a broader user experience of higher audio fidelity for a smaller subset of users.

There are 2 things I am not sure enough:

For clarification, I had permission from DataDrake to update this.