Please present any supporting arguments. And do not forget to account for the fact that vast majority of DA conversion happens in 24bit integer, i.e. any float will have to be converted to 24 bit integer before entering the conversion stage.
The precision you gain by the division in 64-bit float will be lost during the down-conversion, leading to exactly the same results as making the division in 24bit integer, plus the conversion error of 1 LSB which for 24bit is below real-world DAC noise threshhold.
The division operation is linear transformation (plus the rounding error), no matter whether in float or integer. We are talking about a single volume control operation, not about tens of thousands of rounding errors in DSP.
phofman said:
Phofman, thanks for all the pointers and clarification, much appreciated! I will try your suggestions, especially on the pulseaudio resampling (weekend, on ubuntu 8.10). Diving into the code will require a rainy day, I am not a programmer. 🙄
Cheers!
Not sure if I need pulseaudio or not, but I feel it does a lot of things right (I remember alsa... brings back mixed feelings). If I read such a thing I wonder why Jack is then not chosen over pulseaudio in the first place. 🙄
Agreed, DIY audio. 😀
Cool solution! If only reduction of gain is feasible in all cases! If one needs to attenuate, where is that done best? I think digital is a good alternative to analog. For the system I have it makes sense to figure a good way to attenuate the volume using existing (linux) software, as a gain reduction is not possible/recommended for the amplifier. There are alternatives; e.g. to interface to the DAC (ESS Sabbre/Buffalo) and use its internal attenuation (supposedly 28-bit) via I2C commands - which will require more effort, or go analog (which is more evil). I prefer the first 🙂 but it requires fine-tuning and understanding of the linux audio puzzle.
soundcheck said:
A lossless codec sounding worse than WAV because of more CPU use ?
If your system uses a clock recovered from the isochronous USB ticks, it makes sense, but then it is a design flaw in your system, not FLAC.
peufeu said:
peufeu.
I am well aware of the background. (This i tried to figure out in the early days (almost 2 years ago) of this thread) And I am not talking about this particular codec.
If you run extra stuff on your PC, your DAC will tell you.
I tried several DACs including one using asynch USB (EMU 0404USB). I also have the Sabre at home.
If I'd find the right DAC (DIY&reasonable effort&low cost), which is immune against incoming jitter I'd be happy to go for it.
My bet is that 99,99% of all DACs around are not immune against incoming jitter and other
distortions (noise/emi/rfi). For these people, the vast majority - in case they own a high resolution system - it is worth to think of wav vs. flac.
Cheers
No DAC as a separate chip is immune against incomming jitter of the clock. But if 10% increase of CPU load affects DAC clock jitter, it is a fundamental design flaw, just as peufeu notes. The question is for which setup such major influence can actually occur.
Increased EMI/RFI is a popular last-resort argument. But do you have any evidence decoding FLAC produces more electrical noise? E.g. fewer data are read from the disk and transferred across the PCI bus for FLAC.
This is becoming a meaningless discussion.
Increased EMI/RFI is a popular last-resort argument. But do you have any evidence decoding FLAC produces more electrical noise? E.g. fewer data are read from the disk and transferred across the PCI bus for FLAC.
This is becoming a meaningless discussion.
To .: ZMN :.
I find pulseaudio code well structured and documented compared to other projects, such as alsa. Even if his project was not used, Lennart does a great job pushing relentlessly for alsa API cleanup and better documentation.
Personally I think some parts of pulseadio belong to alsa (e.g. the glitch-free support requires very low-level functions for alsa to export), but the daemon part makes sense to me.
I find pulseaudio code well structured and documented compared to other projects, such as alsa. Even if his project was not used, Lennart does a great job pushing relentlessly for alsa API cleanup and better documentation.
Personally I think some parts of pulseadio belong to alsa (e.g. the glitch-free support requires very low-level functions for alsa to export), but the daemon part makes sense to me.
phofman said:
I agree on the big improvements PA brings and large development steps it makes. Very impressive. And I agree that most issues I had were related to other parts of the system (mostly ALSA).
I tried PA when it was announced to become part of several main distro's and had to deinstall it after an afternoon as I could not get things to work better than with alsa - not to say it necessarily was PA; PA is as good as the lower-level part it tries to control/implement.
An example of this: few months ago I was baffled with a non-working soundcard and it appeared that somehow it was set to mute in ALSA. PA and its management interfaces did not give me clues on this and PA is not too blame, it just shows me that with the great features PA brings, the transparency of the Linux sound support is only partly solved.
And yes, I should read the PA documentation better. And yes, eagerly awaiting glitchfree to be included in Ubuntu. 😉
Soundcheck:
Very true. But if you have issues with USB latencies (causing jitter) at 10% CPU load for FLAC decoding, is the other 90% CPU meanwhile used for something else (e.g. brutefir) or at high load (e.g. changing tracks quickly or other programs running)?
Very true. But if you have issues with USB latencies (causing jitter) at 10% CPU load for FLAC decoding, is the other 90% CPU meanwhile used for something else (e.g. brutefir) or at high load (e.g. changing tracks quickly or other programs running)?
Names of controls in ALSA drivers are one big mess. Only slowly start drivers use some naming conventions. It is very difficult for PA to use alsa controls in a generic way (i.e. for any card) when control names differ and their structure is inconsistent among drivers. Due to Lennart's push the issue is being analyzed by alsa admins. I am not worried about the future 🙂
Hi folks.
I just made it work: mpd->brutefir using a fifo! (to enjoy my 64bit-float data-manipulation) 😀
(according to mpd wiki. fifo-out works on the git-version only - I havn't checked it out if it works with the normal version.)
Issue:
I have to start mpd first that the fifo is filled with data. Otherwise I get underrun/file-descriptor problems on the brutefir side and it stops/dies. This should be a brutefir problem.
It should recognize if data is available in the fifo.
I need to check out if this can be solved. Or - do you guys have an idea?
Stop/Pause will make the stream break.
Entire playlist playpack /track change and next/previous functions work.
Which looks a bit strange. I'd expected that during a change of a track the stream
would also break.
1. You have to change your mpd.conf output setting :
audio_output {
type "fifo"
name "MYFIFO"
path "/dev/shm/mpd.fifo"
}
2. Make the fifo
mkfifo /dev/shm/mpd.fifo
3. Change your brutefir config file to read from above /dev/shm/mpd.fifo
input "ileft", "iright" {
device: "file" {path: "/dev/shm/mpd.fifo" ; }; # module and parameters to get audio
4. You start mpd
5. You start brutefir
Enjoy.
I just made it work: mpd->brutefir using a fifo! (to enjoy my 64bit-float data-manipulation) 😀
(according to mpd wiki. fifo-out works on the git-version only - I havn't checked it out if it works with the normal version.)
Issue:
I have to start mpd first that the fifo is filled with data. Otherwise I get underrun/file-descriptor problems on the brutefir side and it stops/dies. This should be a brutefir problem.
It should recognize if data is available in the fifo.
I need to check out if this can be solved. Or - do you guys have an idea?
Stop/Pause will make the stream break.
Entire playlist playpack /track change and next/previous functions work.
Which looks a bit strange. I'd expected that during a change of a track the stream
would also break.
1. You have to change your mpd.conf output setting :
audio_output {
type "fifo"
name "MYFIFO"
path "/dev/shm/mpd.fifo"
}
2. Make the fifo
mkfifo /dev/shm/mpd.fifo
3. Change your brutefir config file to read from above /dev/shm/mpd.fifo
input "ileft", "iright" {
device: "file" {path: "/dev/shm/mpd.fifo" ; }; # module and parameters to get audio
4. You start mpd
5. You start brutefir
Enjoy.
To soundcheck:
The manpage to fifo says:
My guess:
If you look at the source code of brutefir (bfconf.c), it handles the input as a regular file. When it tries to read from the pipe with no writer having it opened, it obtains EOF and quits/dies/.... But reading from pipe works, the documentation even shows the stdin example via shell pipe (|). But in this case it is the shell which opens the writing side of the pipe (and hands it over as stdout to the writing application) before brutefir tries to read from it.
In your case, if brutefir is started before MPD opens the pipe, the pipe is closed on the writing side. What happens if you open the fifo in advance, e.g. by
cat > fifo
before starting brutefir?
EDIT - removed my incorrect fifo size comment
The manpage to fifo says:
My guess:
If you look at the source code of brutefir (bfconf.c), it handles the input as a regular file. When it tries to read from the pipe with no writer having it opened, it obtains EOF and quits/dies/.... But reading from pipe works, the documentation even shows the stdin example via shell pipe (|). But in this case it is the shell which opens the writing side of the pipe (and hands it over as stdout to the writing application) before brutefir tries to read from it.
In your case, if brutefir is started before MPD opens the pipe, the pipe is closed on the writing side. What happens if you open the fifo in advance, e.g. by
cat > fifo
before starting brutefir?
EDIT - removed my incorrect fifo size comment
phofman said:
phofman:
Good to have somebody around who can quickly have a look at the code.
Above makes sense. I am aware of the stdin option mentioned in the brutefir doc.
Unfortunately it seems that I get both apps together by using a fifo only.
The only question which remains: What happens during track change?
Obviously somehow the pipe stays open.
If my assumption is correct then it simply means MPD does not close the output file descriptor when changing track, and it does so when stopping/pausing. It actually makes sense. Why should the player give up the sound device when it knows the track change is fast? Why should the player keep the device open when stopped/paused?
I have not studied MPD source but very probably the internal code uses generic functions for opening/closing/writing to outputs, and the output module defines their actual implementation for each output type (alsa, fifo, jack, ...).
If the above is the case, pre-opening the FIFO writing side externally should help.
I have not studied MPD source but very probably the internal code uses generic functions for opening/closing/writing to outputs, and the output module defines their actual implementation for each output type (alsa, fifo, jack, ...).
If the above is the case, pre-opening the FIFO writing side externally should help.
I just tried your cat-fifo. No success.
It seems that brutefir gets some EOF or whatever as soon as mpd is started.
Until then it seems to wait for data and keeps running.
It seems that brutefir gets some EOF or whatever as soon as mpd is started.
Until then it seems to wait for data and keeps running.
Take a look at audioOutput_fifo.c in MPD. The player opens both ends of the FIFO in non-blocking mode (audioOutput_fifo.c: openFifo). It clocks the amount of data written out using a timer, so that it keeps the output data pace defined by sample rate and sample size of the audio stream (audioOutput_fifo.c:fifo_playAudio).
If the fifo is full, instead of being put to sleep by kernel (if it had been opened in the default blocking mode), the player clears the pipe by reading all the data from the pipe and dropping it (audioOutput_fifo.c:fifo_dropBufferedAudio).
The fifo_dropBufferedAudio gets eventually called in decode.c - see calls of dropBufferedAudio() for operations pause, seek, stop.
Does brutefir quit when you seek in MPD?
What is the actual error message?
What happens if you put "return" at the begining of audioOutput_fifo.c:fifo_dropBufferedAudio, thus disabling MPD reading from the pipe? Perhpas brutefir does not like when something else reads from its input pipe. E.g. it sleeps on empty input pipe, gets awoken, reads and gets nothing (MPD cleared it in between).
At the same time, replace "continue" with "return" at line 258 of audioOutput_fifo.c, otherwise MPD probably locks up at 100% CPU (infinite loop).
Just my 2 cents.
If the fifo is full, instead of being put to sleep by kernel (if it had been opened in the default blocking mode), the player clears the pipe by reading all the data from the pipe and dropping it (audioOutput_fifo.c:fifo_dropBufferedAudio).
The fifo_dropBufferedAudio gets eventually called in decode.c - see calls of dropBufferedAudio() for operations pause, seek, stop.
Does brutefir quit when you seek in MPD?
What is the actual error message?
What happens if you put "return" at the begining of audioOutput_fifo.c:fifo_dropBufferedAudio, thus disabling MPD reading from the pipe? Perhpas brutefir does not like when something else reads from its input pipe. E.g. it sleeps on empty input pipe, gets awoken, reads and gets nothing (MPD cleared it in between).
At the same time, replace "continue" with "return" at line 258 of audioOutput_fifo.c, otherwise MPD probably locks up at 100% CPU (infinite loop).
Just my 2 cents.
1.No it doesn't quit on seek/next song. Just on pause/stop.
2.Error Message: I recall "underrun" / "bad file descriptor".
The exact message I can post later on. But it really seems that
the pipe gets shuffeled.
2.Error Message: I recall "underrun" / "bad file descriptor".
The exact message I can post later on. But it really seems that
the pipe gets shuffeled.
phofman said:
YEP. I can use the seekbar in GMPC and move it back and forth. And next track also works.
- Status
- Not open for further replies.