Tweaker's Rash
Posted: Fri Feb 14, 2014 9:02 pm
How many here have tweaker's rash - (no it's not what you're thinking, "too much fiddling around will cause a rash") - just a bit tired of all the tweaking options associated with computer audio?
I know this may be a contrary opinion on a computer audio section but don't get me wrong, I'm appreciative of all the work/testing/thinking done here & have hopefully contributed a tiny bit to this body of knowledge.
Maybe it's an age thing but I find I'm less & less keen on going through all the variations of computer audio & testing them on my system - it seems that there are just too many variables to contend with. In fact I know it's an age thing as when I was programming I used to enjoy writing & debugging software - now I don't really wan't to have to deal with BSODs or systems that suddenly don't work any more Recently, I had to deal with BSODs on a new laptop after about 3 weeks of using it - had to restore it back to near factory settings. Life's too short for wasting time on that sort of crap
In this CA section we have been exposed to lots of variables - all the various software releases of MQN/JLP - all the different settings (buffers, etc.)/process priorities/bios settings/cables/power supply/etc. It's not that I don't like a bit of tweaking but when the number of variables rises above a certain number it becomes overwhelming & wasteful, as far as I'm concerned.
Does anybody else feel this way?
I've been thinking this for a while now & like a lot here, figured that the way to possibly reduce the overwhelming number of variables was to simplify as many aspects as possible, doh!
I know we have been skirting around this issue here for a while - this may be a possible answer - a Raspberry Pi or equivalent running Squeezelite on a micro Linux OS (RAM resident). This simplifies all aspects - as its an ARM CPU, the power supply requirements are simpler with the distinct possibility of running it from battery. The simpler, RAM based, minimal Linux OS allows better control over the audio task.
The possibility also exists of avoiding another variable - USB (I believe USB on Raspberry is not a great implementation but other platforms also exist that can be used) & running I2S directly into a DAC or a more universal approach - running I2S into a SPDIF converter & then to a DAC. There may also be a possibility of incorporating the JLP as part of this scenario - it probably only requires compiling the source as part of a small Linux core - see Picoplayer https://sites.google.com/site/picoreplayer/home? Gordon might be interested in this area although he seems focussed on Windows JLP?
Edit: Oh yeah, forgot to say that this solution separates the audio rendering device from the audio storage device & can be controlled from a phone, tablet, laptop, PC. You can use a computer (NAS - network attached storage) for storage of your audio files & connect this via Ethernet to whatever is running SqueezeLite
I know this may be a contrary opinion on a computer audio section but don't get me wrong, I'm appreciative of all the work/testing/thinking done here & have hopefully contributed a tiny bit to this body of knowledge.
Maybe it's an age thing but I find I'm less & less keen on going through all the variations of computer audio & testing them on my system - it seems that there are just too many variables to contend with. In fact I know it's an age thing as when I was programming I used to enjoy writing & debugging software - now I don't really wan't to have to deal with BSODs or systems that suddenly don't work any more Recently, I had to deal with BSODs on a new laptop after about 3 weeks of using it - had to restore it back to near factory settings. Life's too short for wasting time on that sort of crap
In this CA section we have been exposed to lots of variables - all the various software releases of MQN/JLP - all the different settings (buffers, etc.)/process priorities/bios settings/cables/power supply/etc. It's not that I don't like a bit of tweaking but when the number of variables rises above a certain number it becomes overwhelming & wasteful, as far as I'm concerned.
Does anybody else feel this way?
I've been thinking this for a while now & like a lot here, figured that the way to possibly reduce the overwhelming number of variables was to simplify as many aspects as possible, doh!
I know we have been skirting around this issue here for a while - this may be a possible answer - a Raspberry Pi or equivalent running Squeezelite on a micro Linux OS (RAM resident). This simplifies all aspects - as its an ARM CPU, the power supply requirements are simpler with the distinct possibility of running it from battery. The simpler, RAM based, minimal Linux OS allows better control over the audio task.
The possibility also exists of avoiding another variable - USB (I believe USB on Raspberry is not a great implementation but other platforms also exist that can be used) & running I2S directly into a DAC or a more universal approach - running I2S into a SPDIF converter & then to a DAC. There may also be a possibility of incorporating the JLP as part of this scenario - it probably only requires compiling the source as part of a small Linux core - see Picoplayer https://sites.google.com/site/picoreplayer/home? Gordon might be interested in this area although he seems focussed on Windows JLP?
Edit: Oh yeah, forgot to say that this solution separates the audio rendering device from the audio storage device & can be controlled from a phone, tablet, laptop, PC. You can use a computer (NAS - network attached storage) for storage of your audio files & connect this via Ethernet to whatever is running SqueezeLite