Filter samplerate conversion
Mervin Beng
In brutefirwrapper Toby generates the filters using sox if the source
samplerate is different from that of the filter:
sox_process = subprocess.Popen(['sox',
'-t','raw',
'-f', # floating point
'-4', # 32 bit
'-r',str(baseline_samplerate),
source_pcm_filename,
'-t','raw',
'-r',str(samplerate),
output_pcm_filename])
I built my filter using sweeps at 48000Hz samplerate, so 44.1kHz and
96kHz filters need to be regenerated.
I use a variant of brutefirwrapper (very much simplified), and pre-
build all the filters. I found that 44.1kHz playback never quite
sounded as good as 96kHz with this new set of 48kHz, so I checked that
my resampled filters are correct. When checking sox documentation, I
found that the conversion I was doing was not quite optimal:
sox -V -t raw -e float -b 32 -r 48000 filter-l.pcm -t raw -r 44100
left44100.pcm
The optimum (according to sox faqs) is the very high setting for
resampling (-v) using the rate command.
sox -V -t raw -e float -b 32 -r 48000 filter-l.pcm -t raw
left44100.pcm rate -v 44100
It could be a placebo, but my 44.1 playback sounds a lot better
(cleaner, less messy) than before. Toby, you may want to replace -r
<samplerate> with rate -v <samplerate> (following the output
filename).
I'd be interested to know if anyone hears a difference with audio of
difference samplerate from the generated drc filter.
Olav Sunde
On Jan 29, 4:15 pm, Mervin Beng <merv...@mail.com> wrote:
you may want to replace -r
> <samplerate> with rate -v <samplerate> (following the output
> filename).
>
I can see that Toby has already implemented your suggestion so this is
what I listen to.. sounds good to me.
I have been thinking of sending PCM to my Touch in stead of FLAC from
the brutefir plugin, but this may not be straight forward. Have you
tried this? I believe I read some posts on this subject at a different
forum. Could that be your posts?
Olav
Mervin Beng
If it's from mervinb or mb, then it's me ;)
To enable flc to pcm, on the web admin / advanced / file types disable flc to flc, and enable flc to pcm for all players. It seems this is needed others the server will default to flc->flc. Then create flc->pcm entries in custom.conf (sox | brufirwrapper), but you will need a brutefirwrapper that does not send the 44-byte wav header.
I have my own wrapper, but unfortunately it uses a slightly different arrangement for filters, so it will no work for you. It's probably easier that I help you get brutefirwrapper working for pcm (only a few lines of mods, and you can eventually send the patches back to Toby).
I ended up writing my wrapper based on Toby's code because at that time it did not support gapless on 96k files well, and Toby's recent revisions are based on my experiments.
BTW, for 96k audio, flc->pcm on wireless did not work well, because the wireless is not fast enough. Pcm needs wired ethernet. I prefer the sound marginally, but I'm not 100% convinced there is real difference. I continue to use it since it uses less server and SBT cpu resources.
Regards,
Mervin
Toby Dickenson
> I have been thinking of sending PCM to my Touch in stead of FLAC from
> the brutefir plugin, but this may not be straight forward.
It *should* be straight forward.
You need to create a template-pcm.conf file in the plugin directory, based on
template-flac.conf, then you can switch between flac and pcm streaming using the
plugin menu. That file defines the conversion pipeline for each file type. For
flac streaming it is:
1. use sox to convert whatever input file to "wavpcm". this is the one specific
variant of wav files which is understood by....
2. brutefirwrapper, which also outputs a wav stream.
3. use flac to convert the wav stream to a flac stream
You need to change step 3 of each pipeline to convert the wav stream to a pcm
stream. I'm sure that sox can do it.... somehow.
Having said that, I strongly suspect it wont objectively make a difference.
There have been posts on the slimdevices forum (which I cant find right now :-(
measuring less than -80dB difference between streaming flac and pcm using audio
diff maker.
--
Toby Dickenson
Olav Sunde
On Feb 23, 10:46 pm, Mervin Beng <merv...@mail.com> wrote:
> Hi Olav,
>
> If it's from mervinb or mb, then it's me ;)
>
>
> arrangement for filters, so it will no work for you. It's probably
> easier that I help you get brutefirwrapper working for pcm (only a few
> lines of mods, and you can eventually send the patches back to Toby).
>
side..
>
> BTW, for 96k audio, flc->pcm on wireless did not work well, because the
> wireless is not fast enough. Pcm needs wired ethernet. I prefer the
> sound marginally, but I'm not 100% convinced there is real difference. I
> continue to use it since it uses less server and SBT cpu resources.
Olav
Olav Sunde
he says - but not all. The main reason I want to try PCM streaming is
that I still have some clicking while playing 88 and 96 material via
the Touch to a HRT music streamer II connected to the USB port. The
HRT works asynchronous with the Touch (with some changes to config in
the Touch). I have no clicking if I disable Brutefir and also no
problems with Brutefir using any of the internal devices of the Touch.
Firmware is 7.5.3-r9283
So I want to see if skipping FLAC decoding on the Touch changes og
stops the clicking. I can also hear a small improvement in sound
quality when Touch receive PCM from the server.
Olav
Mervin Beng
Yes, I've read many of Phil Leighs posts and agree with most of what he says - but not all. The main reason I want to try PCM streaming is that I still have some clicking while playing 88 and 96 material via the Touch to a HRT music streamer II connected to the USB port. The HRT works asynchronous with the Touch (with some changes to config in the Touch). I have no clicking if I disable Brutefir and also no problems with Brutefir using any of the internal devices of the Touch. Firmware is 7.5.3-r9283
So I want to see if skipping FLAC decoding on the Touch changes og stops the clicking. I can also hear a small improvement in sound quality when Touch receive PCM from the server. Olav
Cheers,
Mervin
Olav Sunde
On Feb 24, 10:12 am, Mervin Beng <merv...@mail.com> wrote:
>
> Is this clicking at the start of a track and when skipping to next track
> (>>), or within a track? On 7.5.3 at higher sample rates (or perhaps
> even any rate other than 44.1k), there is a firmware bug that causes the
> spdif to switch back to 44.1 when skipping tracks. Because of this I've
> updated to 7.6 nightly. Recent versions have a fix which keeps the
> sample rate constant when changing tracks (unless the next track
> selected is actually at a different sample rate). Otherwise I can hear
> the dac relay clicking when I skip tracks.
"production" firmware. I also normally run 7.6*. I'll switch back to
7.6 this evening to test.
>
> > So I want to see if skipping FLAC decoding on the Touch changes og
> > stops the clicking. I can also hear a small improvement in sound
> > quality when Touch receive PCM from the server.
>
> > Olav
>
> I'll see what I can do to provide either minor mods to Toby's wrapper,
> or clean up my simplified wrapper for you to test.
be easier to test I believe?
Olav
Mervin Beng
Clicking within the track. I am running 7.5.3 now to test on "production" firmware. I also normally run 7.6*. I'll switch back to 7.6 this evening to test.
I would prefer a mod to Toby's wrapper if that is OK with you. Would be easier to test I believe?
Do you know how I can upload my wrapper to Google Groups? I'm ready to send you something.
FYI, for custom-convert.conf, you will need:
# convert flc to pcm for hall (wired connection)
flc pcm * 00:04:20:xx:xx:xx
# IFT:{START=trim %t}D:{RESAMPLE=-r %d}
[sox] -q --buffer 65536 -t flac $FILE$ -t wavpcm -c 2 -3 -s $RESAMPLE$ - $START$ |
[brutecat] -m 00:04:20:xx:xx:x -f /etc/squeezeboxserver/BrutefirDrc/filters/hall_eq -o pcm
# convert flc to flc with brutefir for bedroom (my wireless too slow for 96k pcm traffic?)
flc flc * 00:04:20:yy:yy:yy
# IFT:{START=trim %t}D:{RESAMPLE=-r %d}
[sox] -q --buffer 65536 -t flac $FILE$ -t wavpcm -c 2 -3 -s $RESAMPLE$ - $START$ |
[brutecat] -m 00:04:20:yy:yy:yy -f /etc/squeezeboxserver/BrutefirDrc/filters/br_eq -o wavpcm |
[flac] -cs -0 --totally-silent -
As you can see, the convert pipe is almost identical to what brutefirwrapper uses. Only difference is the arguments to brutecat. The sox buffer option is not really needed, but should not hurt. Fyi, brutecat will have problems on gapless playback if you use a linear phase filter PSFilterType=L, as I don't do the neat readahead + blending of the tail which Toby's wrapper does. I use PSFilterType=T.
-f = filter
-m = mac address (required)
-o = pcm or wavpcm (for subsequent flac encoding); default = pcm
Credits to Toby for 95% of the code in my wrapper.
Toby Dickenson
> So would I, but I've looked at Toby's wrapper and the way he handles
> arguments to brutefirwrapper (3 args for older version, 2 args for newer
> players) makes it very difficult for me to modify it without the risk of
> breaking things, or writing ugly code. I'm not that strong a coder
> anyway...
Supporting both argument formats was handy during the transition period when
this was introduced a few years ago, but Im sure it can drop support for the 3
arg version now. I will tidy this up....
If possible I would like to merge the capabilities of brutecat into
brutefirwrapper, so we are all working from the same wrapper script. What is
needed?
1. optional pcm output format.
2. option to use pregenerated drc configuration files for different sample rates,
rather than automatically resample the filter.
3. brutecat doesnt have the tail merging feature, which reduces its latency. I
could get brutefirwrapper to support this option, but would prefer to keep it
simple if brutefirwrapper's latency is now low enough that this is no longer
necessary.
> # convert flc to pcm for hall (wired connection)
> flc pcm * 00:04:20:xx:xx:xx
> # IFT:{START=trim %t}D:{RESAMPLE=-r %d}
> [sox] -q --buffer 65536 -t flac $FILE$ -t wavpcm -c 2 -3 -s
> $RESAMPLE$ - $START$ |
> [brutecat] -m 00:04:20:xx:xx:x
> -f /etc/squeezeboxserver/BrutefirDrc/filters/hall_eq -o pcm
How does squeezeboxserver know whether you are output is 16 bit or 24 bit
samples in this case?
> Do you know how I can upload my wrapper to Google Groups? I'm ready to
> send you something.
How about I add you to the sourceforge project and you push the git repo
directly?
--
Toby Dickenson
Toby Dickenson
> The main reason I want to try PCM streaming is
> that I still have some clicking while playing 88 and 96 material via
> the Touch to a HRT music streamer II connected to the USB port. The
> HRT works asynchronous with the Touch (with some changes to config in
> the Touch). I have no clicking if I disable Brutefir and also no
> problems with Brutefir using any of the internal devices of the Touch.
> Firmware is 7.5.3-r9283
One big difference when using brutefir is that your HRT music streamer will
always be receiving 24 bit samples. I have been meaning to implement a 16 bit
output option for a while, to save wireless bandwidth to the player in the
kitchen which occasionally has dropouts.....
> So I want to see if skipping FLAC decoding on the Touch changes og
> stops the clicking.
That makes sense too.
--
Toby Dickenson
Mervin Beng
On Thu, 2011-02-24 at 20:46 +0000, Toby Dickenson wrote:
Supporting both argument formats was handy during the transition period when this was introduced a few years ago, but Im sure it can drop support for the 3 arg version now. I will tidy this up.... If possible I would like to merge the capabilities of brutecat into brutefirwrapper, so we are all working from the same wrapper script. What is needed?
1. optional pcm output format.
2. option to use pregenerated drc configuration files for different sample rates, rather than automatically resample the filter.
if IS_DIR(brutefir_filter):
look for pre-built filters under 44100/brutefir_filter, etc, etc
else:
do as before
With this the user can put the correct filters into sub-directories.
3. brutecat doesnt have the tail merging feature, which reduces its latency. I could get brutefirwrapper to support this option, but would prefer to keep it simple if brutefirwrapper's latency is now low enough that this is no longer necessary.
> # convert flc to pcm for hall (wired connection)
> flc pcm * 00:04:20:xx:xx:xx
> # IFT:{START=trim %t}D:{RESAMPLE=-r %d}
> [sox] -q --buffer 65536 -t flac $FILE$ -t wavpcm -c 2 -3 -s
> $RESAMPLE$ - $START$ |
> [brutecat] -m 00:04:20:xx:xx:x
> -f /etc/squeezeboxserver/BrutefirDrc/filters/hall_eq -o pcm
How does squeezeboxserver know whether you are output is 16 bit or 24 bit
samples in this case?
> Do you know how I can upload my wrapper to Google Groups? I'm ready to > send you something. How about I add you to the sourceforge project and you push the git repo directly?
Thanks for all your good work on this project. More users should be enjoying brutefir/ brutefirdrc. It adds $000s to my listening pleasure.
Olav Sunde
On Feb 24, 11:43 pm, Mervin Beng <merv...@mail.com> wrote:
> Hi Toby,
> > If possible I would like to merge the capabilities of brutecat into
> > brutefirwrapper, so we are all working from the same wrapper script. What is
> > needed?
>
> That would ne nice, thanks.
>
> > 1. optional pcm output format.
>
>
> > 2. option to use pregenerated drc configuration files for different sample rates,
> > rather than automatically resample the filter.
>
> Nice to have, but lowish priority. A possible strategy that doesn't
> break things:
>
> if IS_DIR(brutefir_filter):
> look for pre-built filters under 44100/brutefir_filter, etc, etc
> else:
> do as before
>
> With this the user can put the correct filters into sub-directories.
functionality, which I think is extremely elegant.
Pre-built filters may give even better sound quality or better control
of the filtering in a given setup, but it is also much more advanced
and complex.
>
> Thanks for all your good work on this project. More users should be
> enjoying brutefir/ brutefirdrc. It adds $000s to my listening pleasure.
Olav
Olav Sunde
On Feb 24, 10:59 pm, Toby Dickenson <t...@tarind.com> wrote:
> One big difference when using brutefir is that your HRT music streamer will
> always be receiving 24 bit samples. I have been meaning to implement a 16 bit
> output option for a while, to save wireless bandwidth to the player in the
> kitchen which occasionally has dropouts.....
>
HRT to work properly. I guess most of the trouble here is related to
the rather old USB driver on the Touch giving higher latency than a
more recent version would.
Olav
Olav Sunde
On Feb 24, 10:59 pm, Toby Dickenson <t...@tarind.com> wrote:
>
> > So I want to see if skipping FLAC decoding on the Touch changes og
> > stops the clicking.
>
> That makes sense too.
>
> --
> Toby Dickenson
Even with BrutefirDRC enabled clicking/popping is now gone and
playback up to 24/96 is fine.
Sound quality is good. The HRT MSII sounds better than the built-in DA
in the Touch ( I have bypassed the output caps on the Touch). BUT, and
this is no surprise I guess, the Music Streamer II does not sound it's
best with the Touch. When connected directly to a PC running Vortexbox
using Vortexbox-player, the sound is quite a bit better. I suppose the
same would apply if the Streamer is used with a (properly set up) Mac
or PC. I have not tried this.
I am looking forward to try pcm streaming from brutefirwrapper.
Olav
Toby Dickenson
>> Supporting both argument formats was handy during the
>> transition period when this was introduced a few years
>> ago, but Im sure it can drop support for the 3
>> arg version now. I will tidy this up....
This is now implemented. brutefirwrapper still supports the two-argument format
command line as recent versions, but now also supports the same switches are
brutecat.
If replacing brutecat you now *need* to provide a player id (usually mac
address) using the -c command line switch. This is required for the tail mix
functionality.
>> have been meaning to implement a 16 bit
>> output option for a while, to save wireless bandwidth to the player in the
>> kitchen which occasionally has dropouts....
brutefirwrapper now supports 16 and 24 bit output streams, selected using
brutefir's configuration file. 16 bit output uses less than half the bandwidth,
which is still not enough to fix my occasional dropouts :-(
> > 1. optional pcm output format.
>
> Yes, esp. now that Olav says he can hear a difference.
> > How does squeezeboxserver know whether you are output is 16 bit or 24 bit
> > samples in this case?
>
> Great catch. Since I did not want to truncate brutefir output, it was
> mandatory to have all flacs converted to 24-bit. Space-wise in flac it
> does not take up anything. I figured that if I'm fanatic enough to
> resort to raw pcm playback, why limit to 16-bit? My ripper outputs to
> 24-bits automatically, and I have a batch converter too.
In a quick test it seems squeezeboxserver assumes that a pipeline with a pcm
output stream uses the same sample size as its input stream. So I guess you
never listen to internet radio either.
This is inconvenient for the current brutefir conversion pipeline setup. We use
sox to normalise the input stream, so brutefirwrapper cant know what output it
is supposed to produce.
Anyway, brutefirwrapper now supports the "-o pcm" switch which always produces
pcm output of fixed sample size. This should fill Mervin's and Olav's use cases
(but please check on very low volume first), but I cant recommend this as a
general purpose audiophile option since it can easily produce white noise if
the input sample size is different to your configured output sample size.
> > 2. option to use pregenerated drc configuration files for different
> > sample rates, rather than automatically resample the filter.
>
> Nice to have, but lowish priority. A possible strategy that doesn't
> break things:
>
> if IS_DIR(brutefir_filter):
> look for pre-built filters under 44100/brutefir_filter, etc, etc
> else:
> do as before
I have implemented this by performing a search/replace for "SAMPLERATE" in the
filter file name. So for compatibility with brutecat's pregenerated filters you
would also need to change "-f /path/to/my/filter" to
"-f /path/to/my/filterSAMPLERATE" if your filters are named
/path/to/my/filter44100 etc.
> > How about I add you to the sourceforge project and you push the git repo
> > directly?
>
> I'm mer...@sourceforge.net,
Now added.
> but please be aware I am completely new to
> git, so don't hesitate to caution me if I'm doing things that may mess
> up the repository.
Me too. Everything I know about git came from
http://gweezlebur.com/2009/01/19/my-git-workflow.html
In particular the workflow described as "I don’t usually take much advantage of
the power of Git"....
> Thanks for all your good work on this project. More users should be
> enjoying brutefir/ brutefirdrc. It adds $000s to my listening pleasure.
Thanks,
--
Toby Dickenson
Mervin Beng
Ver 8 works fine, and pretty much meets all my needs. Gapless is pretty much perfect with PSFilterType=T filters, but with L filters, there is a bit of "double-take" at the beginning of the track. Do you hear that? This is for material where there is absolutely no gap, ie. next track is really part of the same music, but logically separated as a track.
On Sun, 2011-02-27 at 21:01 +0000, Toby Dickenson wrote:
> > How does squeezeboxserver know whether you are output is 16 bit or 24 bit > > samples in this case? > > Great catch. Since I did not want to truncate brutefir output, it was > mandatory to have all flacs converted to 24-bit. Space-wise in flac it > does not take up anything. I figured that if I'm fanatic enough to > resort to raw pcm playback, why limit to 16-bit? My ripper outputs to > 24-bits automatically, and I have a batch converter too. In a quick test it seems squeezeboxserver assumes that a pipeline with a pcm output stream uses the same sample size as its input stream. So I guess you never listen to internet radio either.
I only use pcm output for flac, and so far the stations I tune to use mpeg, which I send out as flac.
This is inconvenient for the current brutefir conversion pipeline setup. We use sox to normalise the input stream, so brutefirwrapper cant know what output it is supposed to produce. Anyway, brutefirwrapper now supports the "-o pcm" switch which always produces pcm output of fixed sample size. This should fill Mervin's and Olav's use cases (but please check on very low volume first), but I cant recommend this as a general purpose audiophile option since it can easily produce white noise if the input sample size is different to your configured output sample size.
Yes, I've been caught by this enough times! Safeguard @ line 104, until I get going on git:
if bitspersample==16:
in_format = format_16le()
+ if opts.stream_format=='pcm':
+ sys.exit('%d bit samples are not supported for pcm output'%(bitspersample,))
elif bitspersample==24:
in_format = format_24le()
Regards,
Mervin Beng
if bitspersample==16:
in_format = format_16le()
+ if opts.stream_format=='pcm':
+ sys.exit('%d bit samples are not supported for pcm output'%(bitspersample,))
elif bitspersample==24:
in_format = format_24le()
Toby Dickenson
>> pipeline with a pcm output stream uses the same sample
>> size as its input stream.
If I am right about this then....
> This would work in conjunction with sox *not* forcing the .flac to
> 24-bits for pipelines that will output to pcm. If the source is 16-bit,
> it converts to 16-wav, which then gets caught by the code above.
...this is part of the full solution for pcm streams! brutefirwrapper needs to
patch the brutefir configuration file to ensure that sample sizes match up, the
same way it does for sample rates.
--
Toby Dickenson
Toby Dickenson
> Hi Toby,
>
> Ver 8 works fine, and pretty much meets all my needs. Gapless is pretty
> much perfect with PSFilterType=T filters, but with L filters, there is a
> bit of "double-take" at the beginning of the track. Do you hear that?
> This is for material where there is absolutely no gap, ie. next track is
> really part of the same music, but logically separated as a track.
It sounds perfectly gapless to me (sb3, 44.1kHz)
You can hear something odd at the track transition if using replaygain when
consecutive tracks have different gain values, but I doubt that applies to you.
http://bugs.slimdevices.com/show_bug.cgi?id=9993
Can you post your /var/log/squeezeboxserver/brutefir.log?
--
Toby Dickenson
Mervin Beng
I don't use replay gain, or any of the SB Touch's crossfade functions.
======== brutefirwrapper rev 8 starting at 1299057528 2011-03-02 09:18:48
Resampling brutefir filter from 48000 to 44100
Traceback (most recent call last):
File "/usr/local/bin/brutefirwrapper", line 419, in read_tail
BruteFIR v1.0k (March 2009) (c) Anders Torger
age = time.time()-os.stat(tail_filename).st_mtime
OSError: [Errno 2] No such file or directory: '/tmp/.BrutefirDrc-115/tail-00_04
_20_22_6e_08.pcm'
Output follows (0.523s)
Internal resolution is 64 bit floating point.
Creating 4 FFTW plans of size 16384...finished.
Loading 2 coefficient sets...finished.
Dither table size is 882001 bytes.
Generating random numbers...finished.
Warning: no support for clock cycle counter on this platform.
Timers for benchmarking may be unreliable.
Filters in process 0: 0
Filters in process 1: 1
Audio processing starts now
Readahead complete (1.296s)
Finished!
Output complete (103.984s)
======== brutefirwrapper rev 8 starting at 1299057655 2011-03-02 09:20:55
Resampling brutefir filter from 48000 to 44100
tail is 23s old
BruteFIR v1.0k (March 2009) (c) Anders Torger
Internal resolution is 64 bit floating point.
Creating 4 FFTW plans of size 16384...finished.
Loading 2 coefficient sets...finished.
Dither table size is 882001 bytes.
Generating random numbers...finished.
Starting to write tail-mixed output (0.525s)
Warning: no support for clock cycle counter on this platform.
Timers for benchmarking may be unreliable.
Filters in process 0: 0
Filters in process 1: 1
Audio processing starts now
Finished writing tail-mixed output. Proper output follows (0.838s)
Readahead complete (0.844s)
Finished!
Output complete (39.766s)
<< Here I've changed the filters >>
======== brutefirwrapper rev 8 starting at 1299057885 2011-03-02 09:24:45
Resampling brutefir filter from 48000 to 44100
ignoring tail; it is 190s old
BruteFIR v1.0k (March 2009) (c) Anders Torger
Output follows (0.489s)
Internal resolution is 64 bit floating point.
Creating 4 FFTW plans of size 16384...finished.
Loading 2 coefficient sets...finished.
Dither table size is 882001 bytes.
Generating random numbers...finished.
Warning: no support for clock cycle counter on this platform.
Timers for benchmarking may be unreliable.
Filters in process 0: 0
Filters in process 1: 1
Audio processing starts now
Readahead complete (1.245s)
Finished!
Output complete (103.527s)
======== brutefirwrapper rev 8 starting at 1299058012 2011-03-02 09:26:52
Resampling brutefir filter from 48000 to 44100
tail is 23s old
BruteFIR v1.0k (March 2009) (c) Anders Torger
Internal resolution is 64 bit floating point.
Creating 4 FFTW plans of size 16384...finished.
Loading 2 coefficient sets...finished.
Dither table size is 882001 bytes.
Generating random numbers...finished.
Starting to write tail-mixed output (0.523s)
Warning: no support for clock cycle counter on this platform.
Timers for benchmarking may be unreliable.
Filters in process 0: 0
Filters in process 1: 1
Audio processing starts now
Finished writing tail-mixed output. Proper output follows (0.836s)
Readahead complete (0.841s)
Finished!
Output complete (39.934s)
Toby Dickenson
>>> squeezeboxserver assumes that a
>>> pipeline with a pcm output stream uses the same sample
>>> size as its input stream
This change now uses the same sample size throughout the pipeline, with
brutefirwrapper patching the brutefir configuration file to use 16 or 24 bit
inputs and outputs to match the source stream.
For 16 bit source material this will now be streaming 16 bit samples to the
player (with dithering applied by brutefir). In comparison, when streaming flac
we always send 24 bit samples to the player.
Example configurations are in template-pcm.conf, and you should be able to
select this through the plugin's menu on the player.
If it works right, this should never produce white noise. But for now please
treat this as a beta-quality feature and assume that it might.
--
Toby Dickenson
Mervin Beng
Sadly on the Touch there's no menu available.
Olav Sunde
On Mar 3, 10:09 am, Toby Dickenson <t...@tarind.com> wrote:
> I have just pushed an update which enables PCM streaming for all sample sizes!
>
>
> treat this as a beta-quality feature and assume that it might.
>
share/squeezeboxserver/Bin/i386-linux/sox FAIL formats: can't open
input `-': WAVE: RIFF header not found" and then the Touch displays
"Cannot open file for..."
Olav
Toby Dickenson
> Seems to work fine with FLAC, but I get this error with WAV:
Do you mean that you get this error when playing a wav file, or when streaming
in wav format?
> "/usr/
> share/squeezeboxserver/Bin/i386-linux/sox FAIL formats: can't open
> input `-': WAVE: RIFF header not found" and then the Touch displays
> "Cannot open file for..."
--
Toby Dickenson
Olav Sunde
settings.
Olav
Toby Dickenson
On Mar 4, 9:10 am, Toby Dickenson <t...@tarind.com> wrote:
> On Friday 04 Mar 2011, Olav Sunde wrote:
>
> > Seems to work fine with FLAC, but I get this error with WAV:
>
> Do you mean that you get this error when playing a wav file, or when streaming
> in wav format?
This is when playing a wav file with the new pcm convert.conf
settings.
Obviously, because it is not possible to stream in wav format! I shouldnt post before the first coffee of the day.
> > "/usr/
> > share/squeezeboxserver/Bin/
> > input `-': WAVE: RIFF header not found" and then the Touch displays
> > "Cannot open file for..."
This is a little surprising because this part of the conversion pipeline should be no different to flac streaming. Please check that the sox part of template-flac.conf is the same as template-pcm.conf. Does this wav file play with flac streaming? Is it just this wav file with a problem, or all wav files?
From memory there is a "-t wav" in the input sox command line. I think modern versions of sox should be able to cope without it, and this may help.
Olav Sunde
On Mar 4, 10:19 am, Toby Dickenson <t...@tarind.com> wrote:
>
> I am away from my SB3 at the moment so cant test.
> This is a little surprising because this part of the conversion pipeline
> should be no different to flac streaming. Please check that the sox part of
> template-flac.conf is the same as template-pcm.conf. Does this wav file play
> with flac streaming? Is it just this wav file with a problem, or all wav
> files?
files play.
>
> From memory there is a "-t wav" in the input sox command line. I think
> modern versions of sox should be able to cope without it, and this may help.
wav flc * $CLIENT_MAC_ADDRESS$
pcm-template:
wav pcm * $CLIENT_MAC_ADDRESS$
only difference is -3 in the flac-template which means 24bit?
In brutefir.log I also get this:
======== brutefirwrapper rev 9 starting at 1299185884 2011-03-03
20:58:04
Input to brutefirwapper too short (0 bytes)
Looks like a sox issue to me. I looked a little here http://old.nabble.com/SoX-f527.html
but I have too little time to dig deep at the moment
I can try without -t wav sometime during the weekend. I may be able to
try ogg, aiff etc. too.
Olav
Olav Sunde
When I run this from the commandline I get no errors and the output
file is written.
sox 2444.wav -t wavpcm -c 2 -s 2444.pcm
sox -t wav 2444.wav -t wavpcm -c 2 -s 2444.pcm
Olav
Olav Sunde
wav file. As there is no attachment option in the forum I'll PM the
log to Toby. I have not yet tried other formats than flac and wav.
Olav
Toby Dickenson
What does `which sox` show? I presume /usr/bin/sox
Is it the same if running
/usr/share/squeezeboxserver/Bin/i386-linux/sox
?
--
Toby Dickenson
Olav Sunde
/usr/bin/sox
/usr/bin/sox: SoX v14.3.1
/usr/share/squeezeboxserver/Bin/i386-linux/sox: SoX v14.3.0
Olav
Toby Dickenson
> > > file is written.
> > >
> > > sox 2444.wav -t wavpcm -c 2 -s 2444.pcm
> > > sox -t wav 2444.wav -t wavpcm -c 2 -s 2444.pcm
try:
/usr/share/squeezeboxserver/Bin/i386-linux/sox -t wav 2444.wav -t wavpcm -c 2
-s 2444.pcm
--
Toby Dickenson
Olav Sunde
On Mar 8, 11:03 pm, Toby Dickenson <t...@tarind.com> wrote:
> try:
>
> /usr/share/squeezeboxserver/Bin/i386-linux/sox -t wav 2444.wav -t wavpcm -c 2
> -s 2444.pcm
What about the error in the log
[11-03-08 16:10:51.5139] Slim::Player::Source::_readNextChunk (335)
end of file or error on socket, song pos: 44
[11-03-08 16:10:51.5146] Slim::Player::Source::_readNextChunk (340)
00:04:20:22:28:3a mark end of stream
[11-03-08 16:10:51.5153] Slim::Player::Source::_readNextChunk (348)
Didn't stream any bytes for this song; mark it as failed
[11-03-08 16:10:51.5160]
Slim::Player::StreamingController::playerStreamingFailed (2115)
00:04:20:22:28:3a
[11-03-08 16:10:51.5171]
Slim::Player::StreamingController::_playersMessage (782) Problem:
Can't open file for:: file:///media/Music/a/Touch/wav/1644.wav
Olav
Toby Dickenson
> What about the error in the log
> [11-03-08 16:10:51.5153] Slim::Player::Source::_readNextChunk (348)
> Didn't stream any bytes for this song; mark it as failed
squeezeboxserver did not receive any bytes out of our pipeline. But we knew
that anyway....
On Friday 04 Mar 2011, Olav Sunde wrote:
> In brutefir.log I also get this:
> ======== brutefirwrapper rev 9 starting at 1299185884 2011-03-03
> 20:58:04
> Input to brutefirwapper too short (0 bytes)
brutefirwrapper did not receive any bytes from the previous stage in the
pipeline, which is sox. But that, in isolation, works fine so I'm not sure
where to look next.
> > /usr/share/squeezeboxserver/Bin/i386-linux/sox -t wav 2444.wav -t wavpcm
> > -c 2 -s 2444.pcm
>
> Works fine.
I havent had a chance to try to reproduce this on my system yet..... maybe
this weekend.
--
Toby Dickenson
Olav Sunde
On Mar 9, 9:09 am, Toby Dickenson <t...@tarind.com> wrote:
>
> I havent had a chance to try to reproduce this on my system yet..... maybe
> this weekend.
>
in my collection.
Is this related to Mervin's comment further up where he says "..but
you will need a
brutefirwrapper that does not send the 44-byte wav header."? That was
related to flc ->pcm, but the error in the log also talks about 44
Olav
Toby Dickenson
wav pcm * $CLIENT_MAC_ADDRESS$
# IFT:{START=trim %t}D:{RESAMPLE=-r %d}
[sox] -q -t wav $FILE$ -t wavpcm -c 2 -s $RESAMPLE$ - $START$ |
[brutefirwrapper] -o pcm --copy-sample-format $CLIENT_MAC_ADDRESS$
$FULL_FILTER_PATH$
We can transparently capture the input to this pipeline by changing this to:
wav pcm * $CLIENT_MAC_ADDRESS$
# IFT:{START=trim %t}D:{RESAMPLE=-r %d}
tee /tmp/input.wav | [sox] -q -t wav $FILE$ -t wavpcm -c 2 -s $RESAMPLE$ -
$START$ | [brutefirwrapper] -o pcm --copy-sample-format $CLIENT_MAC_ADDRESS$
$FULL_FILTER_PATH$
But after starting to play a wav track, /tmp/input.wav is definitely not a
valid wav file. So sox is quite right in aborting without providing any output.
This is definitely a squeezeboxserver bug (squeezeboxserver 7.4.2).
--
Toby Dickenson
Toby Dickenson
> This is definitely a squeezeboxserver bug (squeezeboxserver 7.4.2).
It looks like squeezeboxserver is incorrectly seeking past the wav header in
the wav input stream. I have just pushed a workaround for this bug which
involves indicating that this transcoding pipeline can not handle input
streams on stdin. squeezeboxserver gives our pipeline a filename for the wav
file, and we read the file directly.
I dont think this will break anything: Internet radio with wav streams maybe,
but they do not exist.
--
Toby Dickenson
Olav Sunde
is a Readynas Ultra 2 Plus (7.6.0-r9316), the other is Vortexbox
(7.5.3 - r31815).
Olav
Olav Sunde
On Mar 11, 10:44 am, Olav Sunde <ogsu...@gmail.com> wrote:
> Thanks Toby! I'll test this on my two installation this weekend. One
> is a Readynas Ultra 2 Plus (7.6.0-r9316), the other is Vortexbox
> (7.5.3 - r31815).
>
wav, flac, ogg and mp3 --> pcm. All work, but aiff needs the same
setting as wav for the conversion - i.e. # FT:{START=trim %t}D:
{RESAMPLE=-r %d}
Olav
Toby Dickenson
> aiff needs the same
> setting as wav for the conversion
Thanks.
--
Toby Dickenson
Olav Sunde
On Mar 13, 11:41 am, Toby Dickenson <t...@tarind.com> wrote:
> On Sunday 13 Mar 2011, Olav Sunde wrote:
>
> > aiff needs the same
> > setting as wav for the conversion
>
> Thanks.
>
I hear noise for a couple of seconds mixed with music while changing
to the next track. Noise is a bit like white noise and is around 10 dB
down relative to the music. This is when playing an album. 16 an 24bit
is the same. I first heard it through an external DA converter
connected via S/PDIF, but it is also present when using the analog
outs of the Touch.
Olav
Toby Dickenson
> I think there is a problem with track transitions when streaming PCM.
> I hear noise for a couple of seconds mixed with music while changing
> to the next track. Noise is a bit like white noise and is around 10 dB
> down relative to the music. This is when playing an album. 16 an 24bit
> is the same. I first heard it through an external DA converter
> connected via S/PDIF, but it is also present when using the analog
> outs of the Touch.
I would like to think this has the same cause as the "double-take" problem
reported by Mervin. I have not forgotten about the problem, but have only had
a little time to look into it. So far everything has checked out.....
Mervin only hears this on some tracks, and only with linear phase (high
latency) filters. I think that is more to do with the latency making the
problem more or less audible on different tracks (indicating that the problem
depends on the musical signal) rather than there being a problem with linear
phase filters per se.
I can hear the problem in the transition between a pair of tracks which Mervin
sent, but in general do not notice a problem in other music.
Does that sound similar to your problem?
--
Toby Dickenson
Olav Sunde
On Mar 23, 4:10 pm, Toby Dickenson <t...@tarind.com> wrote:
>
> I would like to think this has the same cause as the "double-take" problem
> reported by Mervin. I have not forgotten about the problem, but have only had
> a little time to look into it. So far everything has checked out.....
>
> Mervin only hears this on some tracks, and only with linear phase (high
> latency) filters. I think that is more to do with the latency making the
> problem more or less audible on different tracks (indicating that the problem
> depends on the musical signal) rather than there being a problem with linear
> phase filters per se.
>
> I can hear the problem in the transition between a pair of tracks which Mervin
> sent, but in general do not notice a problem in other music.
>
> Does that sound similar to your problem?
>
> --
> Toby Dickenson
test the same without Brutefir. Filters are created as "True Time
Domain" with Audiolense. I am not sure if these are high latency
filters.
Olav
ogs...@gmail.com
Olav
Toby Dickenson
When streaming as flac, the output of brutefirwrapper is a wav stream which is
piped into the "flac" binary for encoding. In most cases this does the right
thing, but not always. Sometimes it drops a few samples, as Mervin found here.
Sometimes it adds several minutes of silence to the end of the stream. Ive
seen that two or three times previously over the last year - I need to
manually skip to the next track to resume the music, and had always assumed it
was a squeeboxserver bug. Apparently not.
I suspect the problem occurs because our output stream's wav header indicates
that the stream is infinite length, and we rely on the flac program noticing the
EOF. Indeed flac would be producing a relatively helpful error message which
indicates it might not properly handle this case, except for the
--totally-silent command line option we had been giving it :-(
Switching to sox for encoding seems to make the problem go away.
--
Toby Dickenson
Mervin Beng
My initial impression is the Linear filters give more control of reverb, esp. on bass. The overall sound seems a little more polite / reserved, but some of the nastier room modes seem to have shorter decay.
Cheers,
Mervin