Adjusting volume is a single one division operation producing only one rounding error. There is no error cummulation calling for high-precision DSP. 32bit division operation for 16 bit input/output numbers has already 15 extra useless bits (the MSB of the cut-off can be used to decide the LSB of the 16bit output result - standard rounding).
Of course the chosen distribution will have no effect on the resultant bit stream entering the sound card, provided everything in the chain is correct and setup in comparable manner.
Check out sox SoX - Sound eXchange | HomePage , you will find it does all you need and much more
Yes, I agree. My point is, that with gentoo it is easier to assure the correctness of the chain, once one is atop of the learning curve...
Thanks for the tip with SoX, it seems to provide everything I need when capturing from my soundcards ADC.
Rüdiger
What kind of logic is that?
You might climb up the learning curve - which is a very bumpy, steep and long curve to climb.
The biggest challenge though will be to stay on top of it - if you ever manage to get there - to the top.
After a while you'll spent more time on the Linux then on your audio to maintain your position. Been there, done that. ( my ZEN-Kernel adventure with the Gentoo folks)
If a misconfigured mpd.conf almost breaks your neck - I consider that curve even bumpier and longer.
Though it is your choice. Fair enough.BTW - what was your problem with the mpd.conf. Would be nice to share your solution with us. Getting that kind of feedback is quite helpful for people supporting you ( to stay on top of it
). Cheers
Appreciate that lecture, even though it doesn't answer my question .
(If I would have listened to you all the time I'd still be living in (audio-)caves or on (audio-)trees ) Just to get back to my question. Do you know a tool? ( Under Windows I could name several)
Cheers
(If I would have listened to you all the time I'd still be living in (audio-)caves or on (audio-)trees
Whereas now you are living in self-built dreams very apart from reality.
Since it is a mathematical nonsense, I am not surprised developers are not wasting their time. Windows world is full of hard-core audiophiles who need their daily portion of voodoo to keep themselves happy. And if there is demand there is supply.
Tweaking sox source code is trivial - just override the 32bit int with 64bit long int on both sides of the lines where the division occurs. Though I would not be surprised if the compiler optimized-out this extra code since it is a redundant nonsense.
phofman.
They're running floats.
In vol.c and it says:
Though, if I recall it correctly vol is being depreciated.
and also in gain.c
every calculation has a "double" in front of it.
I am not that fast as you in grasping what's going in there ( I am not a programmer). Still I believe by looking inside gain.c, I understood they do all processing in double precision already. Which makes sense. You wouldn't
switch precision in a DSP chain. If it is overkill or not.
Would be nice if you could confirm that. ( Edit: Even though if it would slightly weakening your earlier taken position about Voodoo-Windows designers) )
Cheers
They're running floats.
In vol.c and it says:
Code:
typedef struct {
double gain; /* amplitude gain. */
sox_bool uselimiter;
double limiterthreshhold;
double limitergain;
int limited; /* number of limited values to report. */
int totalprocessed;
} priv_t;Though, if I recall it correctly vol is being depreciated.
and also in gain.c
every calculation has a "double" in front of it.
I am not that fast as you in grasping what's going in there ( I am not a programmer). Still I believe by looking inside gain.c, I understood they do all processing in double precision already. Which makes sense. You wouldn't
switch precision in a DSP chain. If it is overkill or not.
Would be nice if you could confirm that. ( Edit: Even though if it would slightly weakening your earlier taken position about Voodoo-Windows designers)
)Cheers
Last edited:
Klaus,
your attitude is perceived as being arrogant at this end of the line.
With gentoo, I was able to solve my issues, probably because of the in-depth information I found on the web (and did not find for ubuntu).
Gentoo's supported rt-kernel (not the ZEN-kernel) is well documented (though not so easy to find) and compiling your own custom kernel is easy just because of this. No more issues with wrong or suboptimum autoloaded modules, for instance.
The problems with mpd and brutefir was, as is so often, a mixture of several problems. First, mpd wasn't compiled with pipe enabled (I could have sworn I did), then I had typos in mpd.conf ('brutefir -nodefaults /root/brutefir_config' instead of 'brutefir -nodefault /root/.brutefir_config'), last issue was that brutefir is called with mpd's user permissions so brutefir couldn't read its own config file.
Of course, all this silly problems were ... silly, but solvable.
Rüdiger
your attitude is perceived as being arrogant at this end of the line.
With gentoo, I was able to solve my issues, probably because of the in-depth information I found on the web (and did not find for ubuntu).
Gentoo's supported rt-kernel (not the ZEN-kernel) is well documented (though not so easy to find) and compiling your own custom kernel is easy just because of this. No more issues with wrong or suboptimum autoloaded modules, for instance.
The problems with mpd and brutefir was, as is so often, a mixture of several problems. First, mpd wasn't compiled with pipe enabled (I could have sworn I did
), then I had typos in mpd.conf ('brutefir -nodefaults /root/brutefir_config' instead of 'brutefir -nodefault /root/.brutefir_config'), last issue was that brutefir is called with mpd's user permissions so brutefir couldn't read its own config file. Of course, all this silly problems were ... silly, but solvable.
Rüdiger
Perception of arrogance always depends on your personal and emotional view and situation. Just shoot back with facts, that's the best cure for that kind of feeling.
phofman and me are playing games all the time. Either of us could consider the other one being "ignorant" - but arrogant - no that's not it. I just like the challenge behind it. I consider these kind of discussions pretty constructive, since IMO there is usually a certain truth in what's being said from both sides.
Back to your case. It should be allowed to make some comments about "choosing Gentoo because of the correctness of chain". Which still doesn't make any sense to me.
By telling us what was wrong with your mpd.setup - you pretty much confirm what I was referring to. You're on a steep learning curve in Linux-Hacker land.
And your issues had nothing to do with Gentoo, Ubuntu or whatever distro.
Does this sound arrogant?
Cheers
Your question doesn't make sense?
Alsa sends data to the sound card however you want it to. If you are writing code then you simply setup the API the way you want to send your audio and then pump it out
However, you appear to be looking for a way to *read* data *into* alsa and decode your DD data? This is more difficult
Actually I'm pondering something similar for using my PC based convolver to decode DD input over spdif and resend it out over analogue. This has some difficulties such as the DD input will lock the card to the spdif rate (48Khz), but this is acceptable. More tricky is finding an AC3 (or DTS) decoder which will happily take input from spdif - this probably needs coding up
My idea was to build a Jack plugin which reads the spdif input, decodes it using ffmpeg and writes to the analogue output (after processing in Brutefir, etc). If anyone happens to know of something similar already coded then do let me know...?
Alsa sends data to the sound card however you want it to. If you are writing code then you simply setup the API the way you want to send your audio and then pump it out
However, you appear to be looking for a way to *read* data *into* alsa and decode your DD data? This is more difficult
Actually I'm pondering something similar for using my PC based convolver to decode DD input over spdif and resend it out over analogue. This has some difficulties such as the DD input will lock the card to the spdif rate (48Khz), but this is acceptable. More tricky is finding an AC3 (or DTS) decoder which will happily take input from spdif - this probably needs coding up
My idea was to build a Jack plugin which reads the spdif input, decodes it using ffmpeg and writes to the analogue output (after processing in Brutefir, etc). If anyone happens to know of something similar already coded then do let me know...?
Hi folks.
As you might have heard, the Squeezebox Touch is out.
Outputs are Analog and SPDIF/TOSLINK. And it does 24/96.
By tweaking the asound.conf you can even hook up a USB-DAC.
It has a rt- kernel 2.6.26-rt and Alsa 1.0.16 on it. ( Some people are working on upgrading at least Alsa)
The signal quality on the SPDIF is really impressive. I tested it with my Sabre DAC.
Though I had a problem to get my PCM2707 based USB receiver going.
The new local options SD-card and USB data storage will start up a local server and mean extra load to the device. So - better skip that.
Via a special screensaver you can turn the monitor off. I also wrote
a script to turn off WLAN, Samba and some other stuff.
I think the touch is a big improvement in SQ over a "stock" Duet.
Though I am not sure if the new gadgets do add any value. These IMO were just pushing the price up. I turned them all off anyhow.
Still -- at 299€ ( streetprice is even lower) as a complete streaming client incl. high-end audiointerface it must be considered a real hot pick.
Beside that of course you can enjoy the great squeezebox server and the control with iPeng on iPod Touch/iPhone or Squeezecommander on Android.
On the "cons":
Flimsy ethernet jack.
The PS can still be improved by a quality 5V supply.
Old Linux
Cheers
As you might have heard, the Squeezebox Touch is out.
Outputs are Analog and SPDIF/TOSLINK. And it does 24/96.
By tweaking the asound.conf you can even hook up a USB-DAC.
It has a rt- kernel 2.6.26-rt and Alsa 1.0.16 on it. ( Some people are working on upgrading at least Alsa)
The signal quality on the SPDIF is really impressive. I tested it with my Sabre DAC.
Though I had a problem to get my PCM2707 based USB receiver going.
The new local options SD-card and USB data storage will start up a local server and mean extra load to the device. So - better skip that.
Via a special screensaver you can turn the monitor off. I also wrote
a script to turn off WLAN, Samba and some other stuff.
I think the touch is a big improvement in SQ over a "stock" Duet.
Though I am not sure if the new gadgets do add any value. These IMO were just pushing the price up. I turned them all off anyhow.
Still -- at 299€ ( streetprice is even lower) as a complete streaming client incl. high-end audiointerface it must be considered a real hot pick.
Beside that of course you can enjoy the great squeezebox server and the control with iPeng on iPod Touch/iPhone or Squeezecommander on Android.
On the "cons":
Flimsy ethernet jack.
The PS can still be improved by a quality 5V supply.
Old Linux
Cheers
I have a large collection of music on a remote linux file server in my basement. I've got a number of music server daemons running as back ends, including mpd, ampache, etc., that allow me to access the data via a variety of front ends like Rhythmbox, Minion, etc. I'm looking for a hardware interface to the home stereo.
My house is wired for Ethernet. I'd like to tie the remote hard disk-based music collection with the home stereo without having a PC in the listening room. Optimally, I'd like to feed the digital data over the wired Ethernet LAN and perform the decoding at the stereo using a high quality non-USB dac.
What are my options?
Squeezebox Duet, Receiver and Touch seem like viable options, though I can't stand the tiny screen interface for any of them. I need a full sized screen -- nothing smaller than a laptop display.
I currently have my network music servers configured so that I can control them remotely using a Palm Pilot (Bluetooth) or a Laptop (Ethernet) as interfaces to MPD. MPD then routes the streaming output to any MAC address that I select. So I have a laptop for the remote, a filer server holding the data, and a third PC that receives the feed for the stereo. I'd like to eliminate the third PC and replace it with a silent embedded device.
What I'd really like to do is avoid the tiny remote control interfaces (like you have with the Duet) and replace them with a larger remote control like a laptop. Can you recommend any particular options? The Squeezebox Receiver sounds like a potential option, though I can't find information on configuring other devices to control it. Is it possible to use the squeezebox with MPD, or do you have to use the squeezebox server?
thanks.
My house is wired for Ethernet. I'd like to tie the remote hard disk-based music collection with the home stereo without having a PC in the listening room. Optimally, I'd like to feed the digital data over the wired Ethernet LAN and perform the decoding at the stereo using a high quality non-USB dac.
What are my options?
Squeezebox Duet, Receiver and Touch seem like viable options, though I can't stand the tiny screen interface for any of them. I need a full sized screen -- nothing smaller than a laptop display.
I currently have my network music servers configured so that I can control them remotely using a Palm Pilot (Bluetooth) or a Laptop (Ethernet) as interfaces to MPD. MPD then routes the streaming output to any MAC address that I select. So I have a laptop for the remote, a filer server holding the data, and a third PC that receives the feed for the stereo. I'd like to eliminate the third PC and replace it with a silent embedded device.
What I'd really like to do is avoid the tiny remote control interfaces (like you have with the Duet) and replace them with a larger remote control like a laptop. Can you recommend any particular options? The Squeezebox Receiver sounds like a potential option, though I can't find information on configuring other devices to control it. Is it possible to use the squeezebox with MPD, or do you have to use the squeezebox server?
thanks.
Last edited:
Although you asked for non USB, have you considered the small number of apparently decent USB options? eg this gets some good reviews:
devilsound labs - DAC - digital audio cable
If you want non USB then you are left with PCI/PCI Express such as RME/M-Audio or some of the increasingly decent consumer audio devices. Or you use FFADO and some firewire devices (these seem to be very dependent on the correct firewire card in the PC and you may want to buy from a shop with a return policy?)
Some ideas for PC hardware would be Alix 1d, Acer Revo (ion thing) or similar as a cheap PC. Or you could use one of the many media type boxes (lots of them do video, etc, audio). Squeezebox/Sonos would seem to be a decent dedicated option?
Finally you could look at the type of remote control interface you want, it occurs that something which could be driven from an iPad/Dell Streak/Archos 9 - obviously whatever you pick might then drive the software needed?
Good luck
devilsound labs - DAC - digital audio cable
If you want non USB then you are left with PCI/PCI Express such as RME/M-Audio or some of the increasingly decent consumer audio devices. Or you use FFADO and some firewire devices (these seem to be very dependent on the correct firewire card in the PC and you may want to buy from a shop with a return policy?)
Some ideas for PC hardware would be Alix 1d, Acer Revo (ion thing) or similar as a cheap PC. Or you could use one of the many media type boxes (lots of them do video, etc, audio). Squeezebox/Sonos would seem to be a decent dedicated option?
Finally you could look at the type of remote control interface you want, it occurs that something which could be driven from an iPad/Dell Streak/Archos 9 - obviously whatever you pick might then drive the software needed?
Good luck
Thanks for the suggestions.
My goal is to NOT have a PC in the same room as the audio system. I'd like to eliminate power supply fan noise and hard disk noise from the listening environment. This means that I can't have a PC in the room or I have to settle on a small heatsink-type embedded PC with a soundcard. Once you have a PC with a decent soundcard, there's really no need for any other appliance, so the search can stop there. As it turns out, I've already got a dozen PCs in my house. Buying yet another PC isn't a good solution for me. Because my eyes are bad, buying a remote with a display that's the size of a postage stamp isn't very appealing either.
Instead of buying a complete, packaged, turn-key solution, I'd really like to work with what I already have.
I'm hoping to find a simple hardware interface device, not a complete system. The products that provide a hardware device, a software server, a software client, and a remote device aren't what I'm after. I've already got remote devices that are more powerful than what the vendors are selling. I've already got an MPD/iTunes/Ampache/MySQL-compatible back office network server. I've already got the front end clients to run on the remote control devices.
All that I need is an Ethernet-RCA interface, and it seems entirely superfluous to buy all of my hardware/software all over again in a proprietary software package like the Squeezebox Duet.
Unfortunately, the sales paradigm for this kind of off the shelf product involves selling you all four components (converter, server, client, remote) as part of a packaged system where you're paying a huge premium for software and remotes. I'm hoping that I can get what I need (converter) and not have to re-buy Squeezebox's software and remote products that duplicate what I already have.
Maybe I'm just oversimplifying things, but I was hoping that there would be a DIY solution to the problem -- a simple hardware device that converts addressible Ethernet-to-RCA. I was hoping that it wouldn't be much more complicated or expensive than the ubiquitous Ethernet-to-USB converter that you can buy at Wal-mart with pocket change.
It would seem that the E-to-RCA hardware should be pretty inexpensive as well. It's just that nobody is marketing the naked product. Instead of offering a simple device for people who already have the rest of the software/hardware solution, they want to sell the converter wrapped inside of a complete turnkey kit that's offered at a much higher price point than it needs to be.
Does anyone else share this interest or am I the lone wolf crying in the wilderness?
Thanks!
My goal is to NOT have a PC in the same room as the audio system. I'd like to eliminate power supply fan noise and hard disk noise from the listening environment. This means that I can't have a PC in the room or I have to settle on a small heatsink-type embedded PC with a soundcard. Once you have a PC with a decent soundcard, there's really no need for any other appliance, so the search can stop there. As it turns out, I've already got a dozen PCs in my house. Buying yet another PC isn't a good solution for me. Because my eyes are bad, buying a remote with a display that's the size of a postage stamp isn't very appealing either.
Instead of buying a complete, packaged, turn-key solution, I'd really like to work with what I already have.
I'm hoping to find a simple hardware interface device, not a complete system. The products that provide a hardware device, a software server, a software client, and a remote device aren't what I'm after. I've already got remote devices that are more powerful than what the vendors are selling. I've already got an MPD/iTunes/Ampache/MySQL-compatible back office network server. I've already got the front end clients to run on the remote control devices.
All that I need is an Ethernet-RCA interface, and it seems entirely superfluous to buy all of my hardware/software all over again in a proprietary software package like the Squeezebox Duet.
Unfortunately, the sales paradigm for this kind of off the shelf product involves selling you all four components (converter, server, client, remote) as part of a packaged system where you're paying a huge premium for software and remotes. I'm hoping that I can get what I need (converter) and not have to re-buy Squeezebox's software and remote products that duplicate what I already have.
Maybe I'm just oversimplifying things, but I was hoping that there would be a DIY solution to the problem -- a simple hardware device that converts addressible Ethernet-to-RCA. I was hoping that it wouldn't be much more complicated or expensive than the ubiquitous Ethernet-to-USB converter that you can buy at Wal-mart with pocket change.
It would seem that the E-to-RCA hardware should be pretty inexpensive as well. It's just that nobody is marketing the naked product. Instead of offering a simple device for people who already have the rest of the software/hardware solution, they want to sell the converter wrapped inside of a complete turnkey kit that's offered at a much higher price point than it needs to be.
Does anyone else share this interest or am I the lone wolf crying in the wilderness?
Thanks!
Exactly! What I'm thinking about is an Ethernet streaming receiver with its own unique MAC address. You just plug it into any LAN or WAN with an Ethernet cable and access it remotely via TCP/IP. It doesn't have to be a "smart" device. All that it needs to do is to accept data that is streamed to it by a remote server, and feed the ethernet packets to it's own embedded DAC. It would have analog outputs, either single-ended or balanced (or both).
I don't know why somebody isn't marketing something like this -- it would certainly be more convenient than a USB interface (which requires a computer), and it could be designed to eliminate all of the drawbacks that go with USB.
it seems that the vendors who have this technology prefer to sell complete turnkey solutions -- because that gives them the ability to mark up four devices instead of one.
I'm thinking that there's got to be enough collective knowledge in the community to design something like this. The software part has already been done.
I don't know why somebody isn't marketing something like this -- it would certainly be more convenient than a USB interface (which requires a computer), and it could be designed to eliminate all of the drawbacks that go with USB.
it seems that the vendors who have this technology prefer to sell complete turnkey solutions -- because that gives them the ability to mark up four devices instead of one.
I'm thinking that there's got to be enough collective knowledge in the community to design something like this. The software part has already been done.
Last edited:
Yes it is... there are no basic embedded devices that stream over ethernet and feed a dac (if you discount logi-squeeze-tech kit, and people only seem to use them to transport ethernet stream to digital stream nearer their dacs).
Buy a fanless atom board, put it in a 'nice box' and your done... as you said.. the software is already there. Or in the same vain, a tiny VIA based board... your not doing anything interesting with it in your audio room so you need no processing power, a $10 adsl router flashed with the right firmware would achieve the same thing (cough*squeezebox*cough)...
if one of those linux based routers only had non-ethernet outputs we'd be in business.
i don't view this as a niche item. the squeezebox is a very expensive solution to a very simple problem. it would make sense for someone else to try to capture some of this segment of the market.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.