For non-hackers, as I've mentioned before, puppy linux can achieve many of the same things as tiny core promises, but in a more user friendly manner. There is a development suite add-on (and kernel headers) so that you can easily compile apps and drivers, and then remove the development tools when done. I have the latest MPD, alsa, libsamplerate and other apps/libs compiled no probs (there are a lot of pre compiled packages also).
It is 90mb and loads into RAM by default. It comes with a very user friendly interface with a number of useful tools which allow you to tune the sytem to your needs. The community support is excellent.
I am running it as a headless server (no x) booting into ram from a cf card in an IDE adapter. Using the 'universal installer' The system is optimised to reduce reading and writing to these cards. My psu and cpu are fanless, and I have place my reasonably quiet external drive in a cupboard.
Sharing my music drive with the whole network is easy whether windows or linux - a couple of clicks through a wizard and is very light on resources once up.
Previously the real-time kernel I compiled for it broke many of the features. I would like try again to compare phofman's suggestion of reducing the system load through alsa settings vs the realtime minimal buffer approach. Considering that the additional activity of decoding FLAC seems to effect sound in some way, I feel this is a worthy comparison to be made.
If the same can be achieved with tinycore, great less ram will be used. Next to try is wake-on-lan so that I can switch on/off the system from my client PC and try peter daniels mods for the fanless picopsu.
Ross
It is 90mb and loads into RAM by default. It comes with a very user friendly interface with a number of useful tools which allow you to tune the sytem to your needs. The community support is excellent.
I am running it as a headless server (no x) booting into ram from a cf card in an IDE adapter. Using the 'universal installer' The system is optimised to reduce reading and writing to these cards. My psu and cpu are fanless, and I have place my reasonably quiet external drive in a cupboard.
Sharing my music drive with the whole network is easy whether windows or linux - a couple of clicks through a wizard and is very light on resources once up.
Previously the real-time kernel I compiled for it broke many of the features. I would like try again to compare phofman's suggestion of reducing the system load through alsa settings vs the realtime minimal buffer approach. Considering that the additional activity of decoding FLAC seems to effect sound in some way, I feel this is a worthy comparison to be made.
If the same can be achieved with tinycore, great less ram will be used. Next to try is wake-on-lan so that I can switch on/off the system from my client PC and try peter daniels mods for the fanless picopsu.
Ross
Hi Ross,
It's been a long time. Seems that you locked yourself in to get a Puppy up'n running
at your place.
Seems that you progressed quite well.
What struck me about about Tiny Core was the up2date kernel and its core concept.
Puppy won't be something for non-hackers. All of these special Linuxes are IMO for
hackers only. You usually pretty quick end up at a dead end, with your little wishes and problems.
The RAM load is nothing new, I know. Ulis SPB is also doing it.
Cheers
It's been a long time. Seems that you locked yourself in to get a Puppy up'n running
at your place.
Seems that you progressed quite well.What struck me about about Tiny Core was the up2date kernel and its core concept.
Puppy won't be something for non-hackers. All of these special Linuxes are IMO for
hackers only. You usually pretty quick end up at a dead end, with your little wishes and problems.
The RAM load is nothing new, I know. Ulis SPB is also doing it.
Cheers
I have noticed no impact decoding FLAC even 24/176 vs playing wave files on an 800 MHz Alix platform. Flac decode above uses about 25 % overhead vs about 2% for wave. However I'm going almost directly to the hardware (plughw is needed to reformat the 24 bits to the 32 bits needed for my hardware: Juli@).
Am I doing something different? Are others having problems with FLAC? Wave has a real problem with metadata, there is no single accepted standard for metadata for wave so the net result is no consistent support in most software for metadata for wave.
Am I doing something different? Are others having problems with FLAC? Wave has a real problem with metadata, there is no single accepted standard for metadata for wave so the net result is no consistent support in most software for metadata for wave.
Hi Klaus,
Fair enough, I look forward to reading about your experiemnts with tinycore. I am a bit more familiar now with the commandline, compiling etc. Im by no means a 'hacker'. I will perhaps write up my puppy set up in the wiki.
1audio -
If you can't hear a differencce I don't think there is anything wrong. Check the pc audio forum at audioasylum, there are many long threads about this (mostly very boring arguments going over the same point again and again)- nothing conclusive, but many find a difference in sound between formats. I believe I can also hear a difference, it is certainly quite subtle and perhaps all in my head! Most of my library is in flac and I am very happy with it, although I am interested by the unknowns of pc audio.
Anway, my point was that sometimes in this thread, and elsewhere, we are discussing minimising processing as a rule of thumb (e.g. use wav instead of flac, offline processing, don't use additonal audio layers like jack), but more cpu intensive approaches are also promoted, like real time kernels, increased timer Hz, as offering better sound. Phofman had suggested that there might be no need to set the system up to be capable of serving audio to soundcard faster than it can physically buffer it - I can see more rationale for the lower processing route and hope to compare.
It was recently posted on AA that where audio was played back on one machine over the network to another with a soundcard, there was no percieved difference between the playback software (of course all were assumed bit perfect). On a single machine there did seem to be differences using the same dac.
Did you see soundchecks wiki for minion and mpd where it is possible to tag wav?
Fair enough, I look forward to reading about your experiemnts with tinycore. I am a bit more familiar now with the commandline, compiling etc. Im by no means a 'hacker'. I will perhaps write up my puppy set up in the wiki.
1audio -
If you can't hear a differencce I don't think there is anything wrong. Check the pc audio forum at audioasylum, there are many long threads about this (mostly very boring arguments going over the same point again and again)- nothing conclusive, but many find a difference in sound between formats. I believe I can also hear a difference, it is certainly quite subtle and perhaps all in my head! Most of my library is in flac and I am very happy with it, although I am interested by the unknowns of pc audio.
Anway, my point was that sometimes in this thread, and elsewhere, we are discussing minimising processing as a rule of thumb (e.g. use wav instead of flac, offline processing, don't use additonal audio layers like jack), but more cpu intensive approaches are also promoted, like real time kernels, increased timer Hz, as offering better sound. Phofman had suggested that there might be no need to set the system up to be capable of serving audio to soundcard faster than it can physically buffer it - I can see more rationale for the lower processing route and hope to compare.
It was recently posted on AA that where audio was played back on one machine over the network to another with a soundcard, there was no percieved difference between the playback software (of course all were assumed bit perfect). On a single machine there did seem to be differences using the same dac.
Did you see soundchecks wiki for minion and mpd where it is possible to tag wav?
rossco_50 said:
I guess you're talking about John Swensons comment. I did not comment it over there.
He is using Netjack/Jack.You could say that Netjack/Jack becomes the "clock master" slaving the applications to it.
That's why you need to compare an application+alsa vs. X+jack+alsa.
On the remote machine will always be the same load jack+alsa in his setup.
I wouldn't expect a difference by looking at that setup.
rossco_50 said:
I followed the link and it seems a lot of the settings are missing from the current Minion. I can't find options for naming servers (something I could really use) let alone info for wave files.
The real problem with wave files can be solved on an individual level but for Reference Recordings (whom I'm helping with this), chesky and others offering higher res wave files there needs to be a common solution for metadata and there is none. There are many unique solutions but nothing that is transportable from app to app.
Wave vs. Flac- If there is a lot of other processing going on to the file (brutefir etc.) I can see that flac may push the processor and have some impact on the sound, but on a very streamlined setup like I'm trying it seems unlikely that flac would have a problem. I'm serving from the network- no moving parts in the box- and its possible that the smaller flac files may be more reliable.
In general if the sound card is clocked independently of the system, if the data gets to the card on time, consistently and the data is the same ("bit perfect") and if the digital link is adequately isolated (I wish toslink actually worked) then there should be no difference from the sources. However those are significant "ifs".
1audio said:
1. Let me know what settings are missing in the Wiki. I really appreciate feedback to be able improve it.
2.The flac processing seems to impact the sound if done in a realtime chain. Meanwhile
there are players like CPLAY or my own ECASX which do the processing prior to
playback. This way you can enjoy all features Tags and for sure no impact on sound.
3. Streaming the final data stream to an external dedicated audio server based on the discussed mini linuxes, might even be the best solution. But that's work in progress.
I just ordered an Acer Aspire Revo to start that journey.
Soundcheck- I think you got it backward- My installs of Minion is missing the settings in the Wiki. It only has host, port, password and playlist mode. Nothing for server name, cover art for wave etc. Or is there a hidden extra menu I have not found?
I have it all working in Voyage, a pretty mini Linux, running on a cf card. Its a 2GB cf card, which has become almost the minimum available and pretty cheap (4 for $25 at last check). Voyage mounts the card read only so it should have a long service life.
I need a PCI interface for the soundcard so I won't be migrating to a smaller platform soon. If a good USB solution that supports up tp 192/24 on Linux happens then a Shivaplug would be an interesting platform.
I have it all working in Voyage, a pretty mini Linux, running on a cf card. Its a 2GB cf card, which has become almost the minimum available and pretty cheap (4 for $25 at last check). Voyage mounts the card read only so it should have a long service life.
I need a PCI interface for the soundcard so I won't be migrating to a smaller platform soon. If a good USB solution that supports up tp 192/24 on Linux happens then a Shivaplug would be an interesting platform.
soundcheck said:
I fail to see how this is possible... I dont claim to fully understand the process of data flow when decoding a flac file, sending it to a processes and then hardware outputs, but surley there are buffers? And if no buffer under/overrun occurs how can it possibly be any different from playing a raw PCM wav file?
On the face of it I agree that there should be no sonic effect however there are a few "holes" that can let other processes affect the sound.
First- if the soundcard is not running fully asynchronous to the system (its clock is relates (USB) or being modulated by system noise) then changes in load can affect the sound by affecting the clock.
Second, if the system is actually changing the bits- digital level control, digital filtering etc. then the processor load goes way up and its possible for some interaction or even dropped samples in the processing. You would thing that there would be a crash or error thrown if that happened but maybe not.
Third, if the noise in the system isn't adequately isolated from the digital link increased processing will send more noise down the wire. Most cheap soundcards don't have isolation transformers on the digital out, even those that do don't have a lot of isolation in the transformers. Good shielded transformers for a digital link cost as much as the interface chip. If the DAC is in the card it could be much more sensitive to internal processing, simply because of proximity.
The first cause is pretty low probability (except for synchronous USB interfaces). The second and third could be quite real and hard to pin down. They are best dealt with by system design.
First- if the soundcard is not running fully asynchronous to the system (its clock is relates (USB) or being modulated by system noise) then changes in load can affect the sound by affecting the clock.
Second, if the system is actually changing the bits- digital level control, digital filtering etc. then the processor load goes way up and its possible for some interaction or even dropped samples in the processing. You would thing that there would be a crash or error thrown if that happened but maybe not.
Third, if the noise in the system isn't adequately isolated from the digital link increased processing will send more noise down the wire. Most cheap soundcards don't have isolation transformers on the digital out, even those that do don't have a lot of isolation in the transformers. Good shielded transformers for a digital link cost as much as the interface chip. If the DAC is in the card it could be much more sensitive to internal processing, simply because of proximity.
The first cause is pretty low probability (except for synchronous USB interfaces). The second and third could be quite real and hard to pin down. They are best dealt with by system design.
Nobody has a real answer why realtime flac-decoding do cause a slight sound deterioration. The data will be the same that's for sure.
The extra up to 25% processor load for realtime processing might cause certain electrical issues incl. more RFI, more heat, slight power instabilities, etc.
Timing + buffer isssues (much higher latencies) might be another source. ( e.g. People report better sound when reducing their soundcard latencies - realtime flac decoding could mean the opposite)
The PC still is a "BlackBox" from an Audio Perspective.
The extra up to 25% processor load for realtime processing might cause certain electrical issues incl. more RFI, more heat, slight power instabilities, etc.
Timing + buffer isssues (much higher latencies) might be another source. ( e.g. People report better sound when reducing their soundcard latencies - realtime flac decoding could mean the opposite)
The PC still is a "BlackBox" from an Audio Perspective.
Interesting:
Decoding FLAC causes higher CPU load and leads to worse sound.
Running low-latency, RT kernel (1000HZ instead of 200HZ) forces CPU handle many (hundred ?) times more interrupts a second, forces applications respond immediately otherwise xruns occur - leads to better sound.
Or maybe not?
Decoding FLAC causes higher CPU load and leads to worse sound.
Running low-latency, RT kernel (1000HZ instead of 200HZ) forces CPU handle many (hundred ?) times more interrupts a second, forces applications respond immediately otherwise xruns occur - leads to better sound.
Or maybe not?
phofman said:
That was exactly the point I was trying to make in my last post. We were talking about a system timer of 10000Hz (I believe the zen kernel still has this feature) at one point which significantly impacts load, but subjectively has improved sound.
There was an interesting post I saw ay diyhifi which suggested that the biggest impact on audio from a pc would be the constant variation in cpu load, and that the optimum solution would be a consistently loaded cpu, even if this was consistently close to 100%, so that steady power is drawn from the supply. Perhaps the higher timer frequency causes a higher, but more consistent load, and this is what is impact sound?
FLAC decompression loads appear to vary with the amount of audio content over time.
This discussion was actually one of the first one I brought up more than two years ago.
If we'd run a 10.000Hz system clock. The time slot per thread would shrink by a factor of 10.
This means that the audio threads no longer are paused by a 1ms window, they'd run 0.1ms windows.
This means a. variations on the system clock, should impact the realtime stream much less b. threads with low resource and time allocation could be finshed within 0.1ms and wouldn't waste a whole 1ms.
This would leave the datastream much more time and would allow much smaller buffers.
I had a discussion with Ingo Molnar some time ago. He mentioned that a 1000Hz (1ms) clock
could vary easily 100%. With 0.1 ms we might improve that situation.
We need to keep in mind though that the 1000Hz timer is not the only timer on the system.
Two things I'd like to know:
1. How does the overall timer structure look like (HW&SW) How many timers are involved directly and indirectly?
Are all these timers somehow decoupled? I guess they should: From one buffer to another, you'd
need a separate timer.
2. If though - What has latency (buffers) to do with sound variations? ( reference: RME Latency jitter?)
If we'd run a 10.000Hz system clock. The time slot per thread would shrink by a factor of 10.
This means that the audio threads no longer are paused by a 1ms window, they'd run 0.1ms windows.
This means a. variations on the system clock, should impact the realtime stream much less b. threads with low resource and time allocation could be finshed within 0.1ms and wouldn't waste a whole 1ms.
This would leave the datastream much more time and would allow much smaller buffers.
I had a discussion with Ingo Molnar some time ago. He mentioned that a 1000Hz (1ms) clock
could vary easily 100%. With 0.1 ms we might improve that situation.
We need to keep in mind though that the 1000Hz timer is not the only timer on the system.
Two things I'd like to know:
1. How does the overall timer structure look like (HW&SW) How many timers are involved directly and indirectly?
Are all these timers somehow decoupled? I guess they should: From one buffer to another, you'd
need a separate timer.
2. If though - What has latency (buffers) to do with sound variations? ( reference: RME Latency jitter?)
I thought this has been thoroughly discussed here before. The whole chain is clocked by sound card clock (or the 1ms USB controller HW clock). If the SW side cannot keep up, sonically ugly xruns occur. No other buffers matter, the whole chain is asynchronous. There is no blackbox in linux PC audio chain (there are many black boxes in windows though).
The latency setup has no direct influence on the resultant jitter - i.e. on the sound card clock. The only impact can be through noise of power supply/EMI/RMI. I have not seen any study/measurement relating variations in CPU load (percentage points when decoding FLAC in playback rate) to PSU noise.
The latency setup has no direct influence on the resultant jitter - i.e. on the sound card clock. The only impact can be through noise of power supply/EMI/RMI. I have not seen any study/measurement relating variations in CPU load (percentage points when decoding FLAC in playback rate) to PSU noise.
http://www.diyhifi.org/forums/viewtopic.php?f=2&t=1834
See hifizen's comments near the end of the thread. He appears to have seen measurements, but not necessarily related to audio.
When playing back FLAC you can see the bit rate changing, this suggested to me variation within the decompression load - but might not be the case.
The main timer's for midi sequencers are the system timer and the RTC which have been the only ones that have been discussed in this thread in terms of tweaking.
I've linked this guys site before. On the site he runs some jitter tests on some popular linux sequencers and actually shows where timing is lost. To me this really just relates to midi, not playback.
http://tapas.affenbande.org/wordpress/?page_id=40
I am sure there are other internal timers within alsa and dependent on the playback software chosen. Can we not see what these are from source code?
Soundcheck - you seem to put everything to highest rtprio 99, whereas the guy above staggers priority so that the souncard irq is always first. Do you give the soundcard irq rtprio?
See hifizen's comments near the end of the thread. He appears to have seen measurements, but not necessarily related to audio.
When playing back FLAC you can see the bit rate changing, this suggested to me variation within the decompression load - but might not be the case.
The main timer's for midi sequencers are the system timer and the RTC which have been the only ones that have been discussed in this thread in terms of tweaking.
I've linked this guys site before. On the site he runs some jitter tests on some popular linux sequencers and actually shows where timing is lost. To me this really just relates to midi, not playback.
http://tapas.affenbande.org/wordpress/?page_id=40
I am sure there are other internal timers within alsa and dependent on the playback software chosen. Can we not see what these are from source code?
Soundcheck - you seem to put everything to highest rtprio 99, whereas the guy above staggers priority so that the souncard irq is always first. Do you give the soundcard irq rtprio?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.