uli.brueggemann said:
Klaus,
as already written before read the brutefir code.It clearly shows that SND_PCM_FORMAT_S32_LE is assigned to the format definition for the three cases S16_4LE, S24_4LE and S32_LE.
So there is no difference between interpretation of S24_4LE and SND_PCM_FORMAT_S32_LE
Yes I have been in there (5 minutes ago).
That's OK. It just talks about bytes. Somwhere the bytes needs to get shifted.
What I'd need in the end is a stdin S24_4LE and and Alsa S24_LE on the output.
If we talk stdin I need to look into the bfio_file.c
Hi folks.
The workaround for brutefir is to increase the volume by 48db and to configure
in- and outputs as S24_4LE.
(I did not mange to get S24_4LE on input and S24_LE on output working)
brutefir config look s like:
Cheers
The workaround for brutefir is to increase the volume by 48db and to configure
in- and outputs as S24_4LE.
(I did not mange to get S24_4LE on input and S24_LE on output working)
brutefir config look s like:
Code:
filter "leftfilter" {
from_inputs: "ileft"/-48;
to_outputs: "oleft";
process: 0;
coeff: -1;
delay: 0;
crossfade: false; };Cheers
I updated the Wiki with the 24/96 "workaround" configurations for brutefir and ecasound.
BUT PLEASE - WARNING:
You're adding 48db to the signal. Don't mix up your configurations.
You could easily fry your machinery.
Handle with care. Don't blame me, if you mess it up, I don't take any responsibility !!!!!!!!
Cheers
BUT PLEASE - WARNING:
You're adding 48db to the signal. Don't mix up your configurations.
You could easily fry your machinery.
Handle with care. Don't blame me, if you mess it up, I don't take any responsibility !!!!!!!!
Cheers
May I add some considerations to the topic?
BruteFIR is computing with float numbers. It should be mentioned that the valid range for these numbers is -1= < x <= +1. The logarithm of 1 is 0 dB. Thus the maximum output to the soundcard is defined as 0 dB.
Now a 16 bit PCM soundcard does not know anything about the float representation. The range is from -2^15 <= x < 2^15 or -32768 <= x < 32768. So 32768 is considered then a 0 dB.
Reading a 16 bit wav thus means that the input has to be divided by 32768 to get a float number in the allowed range.
Similarly a 24 bit soundcard has a range of -2^23 <= x < 2^23. here the maximum value of 2^23 is considered as 0 dB. Reading a 24 bit PCM input requires a division by 8388608.
For the output to the soundcard the float number has to multiplied by the proper factor to get the right integer number (PCM).
So far so ok.
16 bit are specified as S16_LE, represented by 2 bytes.
But now it is possible to use a 16 bit input also with a 24 bit soundcard. As 0 dB input should also be 0 dB output the input number has to be shifted by 8 bit = factor 256 = 48 dB gain.
$ff$ff are then represented by $ff$ff$00
This should be also clear.
And now the game starts with 24 bit PCM. A computer typically does not like 3 bytes. 2 bytes is ok, also 4 bytes. And so some different formats are invented:
24 bits as $ff$ff$ff
24 bits as $ff$ff$ff$00
24 bits as $00$ff$ff$ff
Formats like S24_LE, S32_LE, S24_4LE or S24_3LE. A bit strange anyway.
It should be also clear that it is necessary to boost by an 8 bit shift to get an equivalent 32 bit PCM number with a given 24 bit PCM number.
What does it mean for a real application?
If a program sends data to BruteFIR then the input section must be able to read the data. And to interprete it correctly. It must read the right count of bytes and maybe it must shift it by 8 bits and it must convert it to a float number.
When BruteFIR sends data to a program or a soundcard it must prepare the data according to the specified program or soundcard format.
So we have different conversions in the game.
Now if Klaus has a S24_3LE output from MPD but Brutefir cannot understand this format he may use S24_4LE. BruteFIR will read 3 bytes and copy it to S24_4LE. An 48 dB boost it necessary to get the right size for the following integer-to-float conversion.
Then Brutefir will do its job.
Now when the result has to be sent to a soundcard it does not help to specify S24_4LE again. The soundcard may just need 24 bits and the specification S24_LE should do the job.
Input and output format are indenpendent and can be set independently.
We can read a wav track by specifying S16_LE, filter the data with BruteFIR and send the result to a soundcard with S24_LE.
I hope this long text helps to understand the problem.
Of course it will be confusing when we now connect a CD player sending 16 bit by spdif to our soundcard and specify the input S24_LE. This also works but only because the proper number of bytes is read and the interpretation is also done correctly. As we do not see outside what is happening we may be simply worried.
I have learnt to keep input and output as 2 different problems. First I always read a 16 bit wav track with Brutefir (this can be easily done with the config file and is 100% safe) and test the output configuration. When the output is working properly then I play with the intended input data and the according specification.
Keep things simple. Never change input and output specs at the same time.
BruteFIR is computing with float numbers. It should be mentioned that the valid range for these numbers is -1= < x <= +1. The logarithm of 1 is 0 dB. Thus the maximum output to the soundcard is defined as 0 dB.
Now a 16 bit PCM soundcard does not know anything about the float representation. The range is from -2^15 <= x < 2^15 or -32768 <= x < 32768. So 32768 is considered then a 0 dB.
Reading a 16 bit wav thus means that the input has to be divided by 32768 to get a float number in the allowed range.
Similarly a 24 bit soundcard has a range of -2^23 <= x < 2^23. here the maximum value of 2^23 is considered as 0 dB. Reading a 24 bit PCM input requires a division by 8388608.
For the output to the soundcard the float number has to multiplied by the proper factor to get the right integer number (PCM).
So far so ok.
16 bit are specified as S16_LE, represented by 2 bytes.
But now it is possible to use a 16 bit input also with a 24 bit soundcard. As 0 dB input should also be 0 dB output the input number has to be shifted by 8 bit = factor 256 = 48 dB gain.
$ff$ff are then represented by $ff$ff$00
This should be also clear.
And now the game starts with 24 bit PCM. A computer typically does not like 3 bytes. 2 bytes is ok, also 4 bytes. And so some different formats are invented:
24 bits as $ff$ff$ff
24 bits as $ff$ff$ff$00
24 bits as $00$ff$ff$ff
Formats like S24_LE, S32_LE, S24_4LE or S24_3LE. A bit strange anyway.
It should be also clear that it is necessary to boost by an 8 bit shift to get an equivalent 32 bit PCM number with a given 24 bit PCM number.
What does it mean for a real application?
If a program sends data to BruteFIR then the input section must be able to read the data. And to interprete it correctly. It must read the right count of bytes and maybe it must shift it by 8 bits and it must convert it to a float number.
When BruteFIR sends data to a program or a soundcard it must prepare the data according to the specified program or soundcard format.
So we have different conversions in the game.
Now if Klaus has a S24_3LE output from MPD but Brutefir cannot understand this format he may use S24_4LE. BruteFIR will read 3 bytes and copy it to S24_4LE. An 48 dB boost it necessary to get the right size for the following integer-to-float conversion.
Then Brutefir will do its job.
Now when the result has to be sent to a soundcard it does not help to specify S24_4LE again. The soundcard may just need 24 bits and the specification S24_LE should do the job.
Input and output format are indenpendent and can be set independently.
We can read a wav track by specifying S16_LE, filter the data with BruteFIR and send the result to a soundcard with S24_LE.
I hope this long text helps to understand the problem.
Of course it will be confusing when we now connect a CD player sending 16 bit by spdif to our soundcard and specify the input S24_LE. This also works but only because the proper number of bytes is read and the interpretation is also done correctly. As we do not see outside what is happening we may be simply worried.
I have learnt to keep input and output as 2 different problems. First I always read a 16 bit wav track with Brutefir (this can be easily done with the config file and is 100% safe) and test the output configuration. When the output is working properly then I play with the intended input data and the according specification.
Keep things simple. Never change input and output specs at the same time.
Great to hear that Anders responded- At least he responds to you. "Several mails" - Hmmh - I just sent him one.
Uli:
Coming back to your long post:
Clarification: MPD sends out ALSA S24_LE ,
which is somehow not ( though I guess it should) the same as brutefir S24_4LE, which as we've seen in the code is actually a S32_LE.
We couldn't find anything for masking/handling of LSB/MSB 0 padding - correct?
With aplay I don't have to increase the volume by 48db. There must be something wrong with the MSB/LSB 0 padding.
I tried S24_4LE on the input and S24_LE on the brutefir output. It just gave me awful noise.
Cheers
Klaus
Uli:
Coming back to your long post:
Clarification: MPD sends out ALSA S24_LE ,
which is somehow not ( though I guess it should) the same as brutefir S24_4LE, which as we've seen in the code is actually a S32_LE.
We couldn't find anything for masking/handling of LSB/MSB 0 padding - correct?
With aplay I don't have to increase the volume by 48db. There must be something wrong with the MSB/LSB 0 padding.
I tried S24_4LE on the input and S24_LE on the brutefir output. It just gave me awful noise.
Cheers
Klaus
BruteEQ
I answered my own questio n re: brutefir control and found BruteEQ but the link appears broken:
http://jukebox.privateradio.org/projects/brutefir/bruteq.php
Anybody know where I can get it
Tom
I answered my own questio n re: brutefir control and found BruteEQ but the link appears broken:
http://jukebox.privateradio.org/projects/brutefir/bruteq.php
Anybody know where I can get it
Tom
Hi folks.
Kai Vehmanen - the guy in charge for ecasound - finally found the solution to our (my? )
24bit MPD/ECASOUND/BRUTEFIR problem.
He - you won't believe it - went through the MPD code and found a feasable solution.
He figured out that the MPD data can also be formated in 32bit on the pipe output.
Guess what! This did the trick.
MPD output formatted to 32bit and input of ecasound/brutefir set to S32_LE and
here we go - it's working
However - the actual 24bit problem of course still exists. He is taking actions to sync all the parties involved.
I am wondering if anybody around here has tried the setup MPD/BRUTEFIR||ECASOUND at all?!!?
OK folks the Wiki is updated - my job for this week is done.
Not to forget: THX a lot to Kai for his great support.
Cheers
Kai Vehmanen - the guy in charge for ecasound - finally found the solution to our (my?
)24bit MPD/ECASOUND/BRUTEFIR problem.
He - you won't believe it - went through the MPD code and found a feasable solution.
He figured out that the MPD data can also be formated in 32bit on the pipe output.
Guess what! This did the trick.
MPD output formatted to 32bit and input of ecasound/brutefir set to S32_LE and
here we go - it's working
However - the actual 24bit problem of course still exists. He is taking actions to sync all the parties involved.
I am wondering if anybody around here has tried the setup MPD/BRUTEFIR||ECASOUND at all?!!?
OK folks the Wiki is updated - my job for this week is done.
Not to forget: THX a lot to Kai for his great support.
Cheers
PulseAudio
I've been experimenting with Ubuntu Studio 9.04 and I'm thinking of removing PulsAudio.
Anybody have thoughts on PulseAudio on an Audio PC - I want to use MPD, Jack, Brutefir, Ardour.
PulsAudio seem to just get in the way and I don't see any advantage to it. I'm having problems setting up RME card with PulseAudio
I've been experimenting with Ubuntu Studio 9.04 and I'm thinking of removing PulsAudio.
Anybody have thoughts on PulseAudio on an Audio PC - I want to use MPD, Jack, Brutefir, Ardour.
PulsAudio seem to just get in the way and I don't see any advantage to it. I'm having problems setting up RME card with PulseAudio
Pulseaudio doesn't seem to have a good reputation among the Linux crowd, with many complaints on the forums about bugs etc. I would only use direct to Alsa apps myself but others need to add features that require a sound server in the chain. With mpd I go direct to alsa via plughw. Its possible to do that with other sources but they won't share the audio system when you do that, it becomes single task with the last app that grabbed it.
Let us know if you get the RME card working. I tried once and ran into some problems and returned the card before I had time to sort the problems out.
Let us know if you get the RME card working. I tried once and ran into some problems and returned the card before I had time to sort the problems out.
Pulseaudio is not intended for audiophiles playback but for easy manipulation with audio streams. It makes perfect sense for user-friendly distributions, though probably no sense for Ubuntu Studio.
Its code is constantly evolving, often alsa-lib and even alsa drivers get changes to support some well-argued pulseaudio requirements.
Its code is constantly evolving, often alsa-lib and even alsa drivers get changes to support some well-argued pulseaudio requirements.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.