Yeah, it is there. I put pstree -a -l -p > /tmp/pulse.tree into the script and it shows pactl called from the start-pulseaudio-x11 script.
Well that is a very nice figure
Pavel.
Do you see a chance to use the very high quality resampler of soxr instead of libsamplerate rate best-sinc ??
I'd be interested in the VHQ linear resampler of soxr.
I've seen that ffmpeg seems to use libsoxr nowadays. The comparisons on infinitewave cleary show the similarity to sox. ffmpeg doesn't seem to use
highest quality with steepest filter settings though.
PA offers ffmpeg as resampling option, but it doesn't seem to work properly.
And I do not know what resampler ffmpeg would be using.
I compared the best-sinc to the internal resampler of my TEAC UD-501.
The Teac internal resampler is more punchy in the low end and more dynamic overall. They are not very far apart. However. I do think that I could gain a little using the sox resampler.
Cheers
Do you see a chance to use the very high quality resampler of soxr instead of libsamplerate rate best-sinc ??
I'd be interested in the VHQ linear resampler of soxr.
I've seen that ffmpeg seems to use libsoxr nowadays. The comparisons on infinitewave cleary show the similarity to sox. ffmpeg doesn't seem to use
highest quality with steepest filter settings though.
PA offers ffmpeg as resampling option, but it doesn't seem to work properly.
And I do not know what resampler ffmpeg would be using.
I compared the best-sinc to the internal resampler of my TEAC UD-501.
The Teac internal resampler is more punchy in the low end and more dynamic overall. They are not very far apart. However. I do think that I could gain a little using the sox resampler.
Cheers
Interesting issue and surprising timing - I spent some time last night on this. The easiest way for now is to recompile soxr package (debian/ubuntu offers single-command tools for that) with a trivial change:
Here The SoX Resampler library / Code / [988f83] /src/soxr.h are the individual quality enums/receipts for libsoxr (not libsamplerate!)
The SoX Resampler library / Code / [988f83] /src/soxr-lsr.h are enum for libsamplerate qualities
The conversion libsamplerate -> libsoxr qualities is here The SoX Resampler library / Code / [988f83] /src/lsr.c . The sum corresponds exactly to enum values in soxr.h - 8, 9, 10 in descending quality.
And here The SoX Resampler library / Code / [988f83] /src/soxr.c a conversion to precision happens:
0-3 = 16, 4-7 ascending from 20 to 32 stepped by 4, and finally those we are interested in - 8-10 descending from 23 to 15. Today Rob explained the values 23, 19, 15 are best match for corresponding libsamplerate algorithms, he did study libsamplerate very thouroughly. Fair enough, he is aiming at closest compatibility, not at best resampling results available.
Now all you have to change is the resultant quality of libsoxr recipes for libsamperate (8, 9, 10) to something else you want.
I would extend the if-elseif section at https://sourceforge.net/p/soxr/code/ci/master/tree/src/soxr.c#l84 to include values 8, 9, 10 and rewrite the quality to whatever you want between 3 - 7, as defined in https://sourceforge.net/p/soxr/code/ci/master/tree/src/soxr.h#l281
E.g. sox_vhq corresponds to SOXR_28_BITQ - value 6 - defined just above the quality values.
IMO that's all you have to do. The code is very clean and easy to understand (until one hits the actual resampling magic
)I am afraid I do not have time to try that but you should be able to do that easily - HowTo recompile Debian packages - MDLog:/sysadmin
Last edited:
Hi folks.
Gotta question.
As some of you might know I'm using squeezelite and logitechmedia server on my network. And this is still my prefered setup. ( MPD IMO
can not compete with such a setup. )
However. I'm always looking for a change.
I'm wondering if there is very slim and efficient UPNP client application available under Linux. Basically comparable to squeezelite in the squeeze universe, which can be run on a small device like a RaspberryPi. It could also be just a UPNP frontend client, which can pipe a stream into sox/ecasound/brutefir for further processing.
THX
Cheers
Gotta question.
As some of you might know I'm using squeezelite and logitechmedia server on my network. And this is still my prefered setup. ( MPD IMO
can not compete with such a setup. )
However. I'm always looking for a change.
I'm wondering if there is very slim and efficient UPNP client application available under Linux. Basically comparable to squeezelite in the squeeze universe, which can be run on a small device like a RaspberryPi. It could also be just a UPNP frontend client, which can pipe a stream into sox/ecasound/brutefir for further processing.
THX
Cheers
The libsoxr-lsr LD_PRELOAD trick does work with MPD too! 
www.audiofaidate.org - View topic - MPD (Music Player Daemon)
www.audiofaidate.org - View topic - MPD (Music Player Daemon)
The libsoxr-lsr LD_PRELOAD trick does work with MPD too!
www.audiofaidate.org - View topic - MPD (Music Player Daemon)
Cool. I like the way Rob offers the "SoX VHQ" configuration for legacy libsamplerate applications.
Pavel.
1.
Do you know if the scratch issue has been resolved with libsoxr?
I think you mentioned something earlier.
I do experience some srcatches at the end of a track, when using standard sox for realtime upsampling. Im not sure yet if it squeezelite or sox is causing this. Especially on gapless albums this it not nice . Sounds as if a turntable would lift up the needle.
2.
Is standard sox also using this efficient libsoxr code?
Cheers
1.
Do you know if the scratch issue has been resolved with libsoxr?
I think you mentioned something earlier.
I do experience some srcatches at the end of a track, when using standard sox for realtime upsampling. Im not sure yet if it squeezelite or sox is causing this. Especially on gapless albums this it not nice . Sounds as if a turntable would lift up the needle.
2.
Is standard sox also using this efficient libsoxr code?
Cheers
Hi Klaus,
Yes and no. Discussion with Clemens [alsa-devel] pcm_rate API question revealed the existing rate plugin infrastructure requires fixed number of output samples which is not satisfied with libsoxr. As a result Rob wrote a core of separate libsoxr rate plugin which I promised to finish and push upstream. Not yet ready on my side, though, at bit of crisis at work
Could be a problem with squeezelite. I have never encountered artifacts with regular sox.
The library is inspired by the sox algorithm, just like the sox library in foobar. The source code is a bit different, IMO. Sox does not use the soxr library.
Yes and no. Discussion with Clemens [alsa-devel] pcm_rate API question revealed the existing rate plugin infrastructure requires fixed number of output samples which is not satisfied with libsoxr. As a result Rob wrote a core of separate libsoxr rate plugin which I promised to finish and push upstream. Not yet ready on my side, though, at bit of crisis at work
Could be a problem with squeezelite. I have never encountered artifacts with regular sox.
The library is inspired by the sox algorithm, just like the sox library in foobar. The source code is a bit different, IMO. Sox does not use the soxr library.
I guess you use sox with -v!? With the stopband so high this can't be avoided. Give it a try without -v and don't wurry, a stopband at -120dB is still more then plenty.
Pavel have already given a more proper answer. Yet, from a more "empirical" POW, I can report that in several days of use (with MPD) I have never heard such a problem.
MPD may work differently (perhaps we can say "correctly") with the resampled results.
More info about the problem of -v here:
Upsample 44.1 24-bit to 48 24-bit for DVD - Hydrogenaudio Forums
When you read there you can see foobar for example can solve the problem with not resetting the resampler between tracks.
@soundcheck
I guess Squeezebox server is the piece of software that has to change behaviour. Did you try without -v meanwhile?
Upsample 44.1 24-bit to 48 24-bit for DVD - Hydrogenaudio Forums
When you read there you can see foobar for example can solve the problem with not resetting the resampler between tracks.
@soundcheck
I guess Squeezebox server is the piece of software that has to change behaviour. Did you try without -v meanwhile?
I'll check it out.
I currently use this custom-convert.conf setup:
Code:
flc flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -D -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -I -a -b 98 96000Does anybody have a different proposal ?? Taking out -v is one.
Background info:
Even though I'm generally trying to avoid resampling, I figured that sox resampling delivers better results then the resampling done by my DDX320 full digital amp, which resamples everything to 24/96 first.
Thx all of you for the infos so far.
Last edited:
my thoughts about upnp
what are devices that uses upnp and their usability?
if we are talking about streaming. nfs is most fastest way
what i now upnp devices interact when i don't want and can't comply when i want
was it soundcheck who brought it up.
This is getting to crowded may be we splice it up and make new category called linux audio
what are devices that uses upnp and their usability?
if we are talking about streaming. nfs is most fastest way
what i now upnp devices interact when i don't want and can't comply when i want
was it soundcheck who brought it up.
This is getting to crowded may be we splice it up and make new category called linux audio
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.