Re: [SlimDevices: Audiophiles] External DAC on Transporter: best output option
Golden Earring wrote: > Like Wallace (of "& Gromit" fame), I have found the need to break off > for some cheddar at this juncture. > Come on now, it's got to be Wensleydale. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=106519 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Intona USB thing
foxesden wrote: > Any ideas why this might be? I had level matched before putting the > thing in the chain and it must be 10 db louder - I mean it hurt. Clutching at straws - something really bad was happening in the analogue chain via the ground connection before the Intona thing isolated the grounds. Something like one half of a differential connection somehow 'shorted' to ground somewhere... utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=106914 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] So they recommend Cat8 ethernet cables now!?
drmatt wrote: > Well, 24/48k would be less than twice the capacity. I'm interested to know what the typical FLAC file size is at 24/48k compared to 16/44.1k. I'd expect the 24/48k to be a lot larger than the ratio of the uncompressed bit-rates (1.6:1) might suggest. I only have 16/44.1k FLAC tracks (all CD rips), and these seem to be compressed to around 50% of the uncompressed size. The extra 8 bits in 24-bit audio data most probably look like noise to the FLAC prediction algorithm, so I'd expect the compression to be much less efficient than for 16-bit audio - perhaps only 80% of the uncompressed size? That would make 24/48k files around 2.5x the size of 16/44.1k ones. If the ratio is much better than that, I'd question if the 24-bit version really is 24-bit, and not just zero padded from the 16-bit! utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=106593 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Euphony Audio
edwardthern wrote: > We are talking about jitter from the source. Explain what you mean by that and how it is relevant to audio quality. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=106578 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Euphony Audio
edwardthern wrote: > _ > > HERE_IS_SOME_INFO_FROM_REDHAT...[IF_YOU_CAN_BELIEVE_THEY_KNOW_WHAT_THEY_ARE_TALKING_ABOUT]_ > Newer CPUs may alter their performance based on a workload heuristic in > order to save > power. This is at odds with latency-sensitive workload requirements, > causing sub-optimal > performance/jitter. > > here is limited flexibility with regard to kernel threads as > compared to userspace threads. Here are some options for task affinity > and isolation to > reduce jitter and latency:Isolate CPU cores from > userspace tasks > . > > https://access.redhat.com/sites/default/files/attachments/2012_perf_brief-low_latency_tuning_for_rhel6_0.pdf > > > FYI, plenty of more information on the Web. Texas Instruments, RedHat > and plenty of other companies with the money and staff to do "real" > research can provide a lot of good data. All of my tweaks etc. comes > from them as suppose to arm-chair engineers found in forums. > > Years ago I read an article by Texas Instruments which clearly showed > the results of an experiment that showed the correlation between USB > wire length and jitter.even as USB trace increased on motherboards > jitter increased. Of course as predicted people laughed at me and said I > was crazyclinging to the idea of some crap about digital data via > spdif needed to be >1.5m and applying that to USB [because it too was > digital data]. The "jitter and latency" referred to in that Redhat article is the delay and variability in scheduling of real-time threads. Nothing at all to do with the jitter of a clock in a DAC. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=106578 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Study finds ...
cliveb wrote: > Anyone have any more details about this study? Full paper is freely available here: http://www.aes.org/journal/ utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=105816 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Is anybody sick of the recent spate of threads?
darrenyeats wrote: > Thanks Mynb, > If the aim is not to truncate, the first numbers I expect to pop out are > binary roots of 65536 (i.e. powers of 2) e.g. 256, 512, ..., 16384, > 32768. Their absence indicates that avoiding truncation was not a goal > at all. > The table gain values of 2048 and greater are all multiples of 256. That means if you multiply 16-bit data by the table values, the least significant 8 bits of the 32-bit result will be all zeros - so there is no truncation when the most significant 24 bits are fed to a 24-bit DAC. The 2048 gain value corresponds to -30.1dB. With lower gain values than that there is truncation. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103842 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] generating free energy by using chrystal
arnyk wrote: > At the least wind turbines can extract energy from wind without slowing > it, as they can extract significant energy by just making the wind > turbulent, thus increasing its entropy. The wind turbine can't extract any energy without slowing the wind down - as the wind passes the turbine disk there is a step change in wind speed, with the change in kinetic energy of the wind being where the power comes from. Producing turbulence - initially in the form of bound and tip vortices - is an essential part of generating lift and power, fundamentally limiting the efficiency of the energy conversion. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=104207 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] generating free energy by using chrystal
ralphpnj wrote: > Truer words have never been spoken or written. > > Sounds to me like you know EXACTLY what you're talking about :) I agree that changing to electric cars is a pretty stupid thing to do if we keep generating the electricity with fossil fuels. I think the article was about a lot more than that... utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=104207 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] generating free energy by using chrystal
ralphpnj wrote: > So please explain how STORAGE batteries are going to save the world from > climate change being caused by burning fossil fuels? On their own they aren't going do anything, of course. But most forms of renewable energy will also require huge amounts of energy storage in order not to still require fossil fuel generators on standby to fill in the gaps. And with pretty well all forms of energy usage moving over to electricity, this standby capacity would actually need to be many fold larger than the total current fossil fuelled generating capacity, to cover those windless and sunless times. So energy storage is still a very important thing to be working on... utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=104207 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] generating free energy by using chrystal
ralphpnj wrote: > On a related note concerning the lack of understanding of basic > scientific principles check out this article on batteries published in > yesterday's Christian Science Monitor: > > http://www.csmonitor.com/Environment/Energy/2015/0830/How-a-new-battery-revolution-will-change-your-life > > Basically the article fails to fully understand that the batteries being > discussed are storage batteries and the power being stored by the > batteries has to come from another power source. So while the article > does mention that these batteries can used to make solar and wind power > available during times of no sun or wind, it fails to understand that > the vast majority of electricity that goes into the vast storage > batteries initially comes from a power plant burning fossil fuels, > particularly those being used in electric automobiles. Add to this the > fact the article manages to discuss the future batteries and energy > without even the slightest mention of climate change, climate change > that is being driven by the burning of fossil fuels. I disagree. I think the author understands the scientific principles very well; the undertone of the article is very much about energy storage being an very important part of a renewable energy future. Numbers are important though - and this article fails to put the few numbers it has into proper context, as is usual... Some numbers I can see there are: current battery storage is 100GWh, expected to increase to 160GWh by 2020 - these are meaningless figures to most readers. Better is "Musk calculated it would take roughly 2 billion Powerpacks to electrify the entire world". If those are his 10kWh packs, I make that 2e13 Wh of storage capacity, or 200 times current battery storage capacity above. I big step up, but doable I guess. Is even that enough though? Here's some numbers I've just extracted from http://www.iea.org/publications/freepublications/publication/keyworld2014.pdf : 2012 total annual worldwide energy consumption: 1.04e17 Wh/year. Only 20% of that is electricity, the rest of it is basically fossil fuel burnt at point of use in an engine, for heating or some chemical process. In a renewable energy future the whole lot would essentially need to be electricity. And that number is only going to get bigger... Musk's 2e13 Wh of storage would keep the world running for 100 minutes. I'd venture to suggest that at least a whole day's worth of storage capacity would be needed to buffer out the variability in solar and wind power. I.e. 14 times as much as Musk suggests - 28 billion of his Powerpacks or 2800 times current battery storage capacity... Perhaps a more practical energy storage technology is kinetic energy storage, ultimately in the very useful form of a Launch Loop: http://launchloop.com/PowerLoop. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=104207 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] MEASUREMENTS: PonoPlayer!
Archimago wrote: > Just thought this spectral frequency plot looked interesting for the > PonoPlayer! > > Lots of high-frequency gets through of course but not the usual Nyquist > ringing. Linear with no phase shift in the higher frequencies. An > interesting low frequency "afterimage" in the plot. (Not sure how else > to call this... Any thoughts?) > > 18569 Maybe just showing the DC decay resulting from AC/capacitively coupled output. I.e. the impulse injects a very small amount of DC which decays over a few ms - perhaps no overshoot/ringing involved in that at all. I assume the timescale ticks are 1ms? utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=104094 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Is anybody sick of the recent spate of threads?
jkeny wrote: > I know it's 140/8 but where are you getting the 8 from? > Oh dear. Again. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103842 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Is anybody sick of the recent spate of threads?
MichaelJ wrote: > We? You don't care...don't presume to speak for me! Nor me. I do care, and have found the recent combative threads quite entertaining. There is also quite a bit of information coming out from Archimago and Arny that I find quite interesting. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103842 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Is anybody sick of the recent spate of threads?
toby10 wrote: > Seriously? Close the forum because you dont like it? I find it > entertaining, obviously others agree. > > If you are that offended by this forum then simply stop reading & > posting to this forum (which is the same result as closing the forum . > for you). Meanwhile leaving well enough alone for those who do enjoy > it. > > I dont like tofu as its taste & texture offends me. But Im not going > to lobby my local grocer to stop selling it or ask the moderators of the > tofu forums to cease. Silly! > > http://able2know.org/forum/tofu/ I agree; keep it open. It is all very entertaining. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103842 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] uptone audio regen
jkeny wrote: > Do they? The structure of the digital signal I2S signal (the one that > operates at chip level) is a serial stream of data bits, Right channel > sample first then followed by Left channel sample. In modern DACs there > are 32 bits in each sample. Each of these bits is clocked on a separate > tick that is derived from the clock. So it is very possible that during > the right channel sample timing will be affected by clock jitter & that > there is a completely different clock jitter profile during the left > sample processing > > You are trying to maintain that clock jitter affects both channels > identically. Again, please!! Utter hogwash. Do you know anything about > how DACs operate or is all this BS just trying to impress the lay > person? > > Do you really think that the Bit clock (which is derived from the audio > clock) times the bits into both channels synchronously?? Your lack of > the basics is really embarrassing Oh dear. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103684 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Internet Blind Test: Linear vs. Minimum Digital Filters...
arnyk wrote: > The literature related to doing this kind of listening test contains > many examples of attention and inattention to the potential for > nonlinear distortion (e.g. IM) in the monitoring system to cause false > positives. > > This pair of sample-rate-testing files contain the results of several > generations of trying to build a listening test that is self-diagnostic > for this problem: 'Link to files for studying the audible effects of > downsampling that are also self-diagnostic for IM' > (http://www.hydrogenaud.io/forums/index.php?showtopic=107570&view=findpost&p=894877) > > The way this works is that the primary test is the classic "Keys > Jangling" sound originally recorded at 24/96 and then downsampled to > 44/16 and upsampled back to 24/96. Following the keys jangling sound is > a brief low level marker tone followed by ultrasonic test tones > designed to elicit audible IM if there is excess nonlinear distortion in > the monitoring chain. > > The intent is that an ABX file comparison tool such as Foobar2K with its > ABX plug-in (all freeware) are used to control the test. > > In the basic test (keys jangling, before the audible test tone) the > intent is that you either hear or do not hear a difference. That's the > primary test. > > Following the low level test tone is the secondary qualification test > for your monitoring chain. If you hear any difference between the files > in this test segment, (or hear anything but silence or a very faint low > level rushing noise) then your monitoring chain has audible IM and any > positive results from the primary test are probably the results of that. > IOW, false positives. Thanks for that Arnold. I'm glad you guys are doing your best to test this properly, as a counter to the somewhat warped methods of those with commercial interests at heart. As an aside, I've recently updated one of my long term projects (involved with genuine ultrasonic content) to take advantage of the ready availability of low cost 192KHz ADC/DAC devices now. I'm really impressed with the performance, but for me - especially with my ageing ears - it is utterly pointless (and quite possibly detrimental) to use such high sample rates for music. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103537 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Internet Blind Test: Linear vs. Minimum Digital Filters...
I'm coming late to all these discussions, so forgive me if I'm covering old ground here. As an engineer that has worked for many years in all sorts of fields involved in signal processing, I've found the difficulties with wide-band high resolution systems are mostly to do with non-linearities. I suspect that if people can actually hear a difference between wide bandwidth input vs. the same thing low-pass filtered - that we know shouldn't be audible - this is probably a non-linearity defect in either the reproduction equipment or receiving apparatus (i.e. the ears). Most likely the ears. In other words, those that think they've got 'golden ears' because they can hear a difference maybe shouldn't be too proud - it could well be because their ears are unusually non-linear, i.e. defective. It could, of course, be a non-linear defect in the (expensive) wide-bandwidth amplifier/speaker/listening environment combination being revealed with this new-fangled high-sample rate source material. That might be equally problematic utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103537 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Digital Music Systems - track limits!?
probedb wrote: > It isn'tand you just changed the goalposts. Let's take just one > track from my collection: > > Artist Name: 65daysofstatic > Track Title: The Distant & Mechanised Glow of Eastern European Dance > Parties > Album Title: The Destruction of Small Ideas > > ...just broke your reasonable limit and that's without anything > including track number, genre, date, total tracks or any number of other > common fields. yes you have shorter fields but 100 as a reasonable > average, come on I think not. The track title may be slightly longer > than average but the Artist Name and Album Title certainly aren't. > > My collection is very well organised thanks. I wasn't referring to how you might organise your collection, just how a to well organise an in-memory database for efficient use of memory... Ok, some numbers from my modest and motley collection of 14000 odd tracks. It's mostly full albums, with plenty of long names like above. Also a large number of compilations (i.e. different artists per track), a lot of classical (few tracks per work/album, with long track names), and for a large proportion of the tracks there are multiple artists (composer, 'featuring' etc) per track. These numbers come from my own LMS controller app I did ages ago for Symbian, where the full track/artist/album/genre/year data is downloaded from LMS and stored in-memory in the phone. So, for 13828 tracks, 6304 artists, 1159 albums, 63 genres, 52 years, there are 424480 bytes of UTF8 strings. That's only 31 bytes per track. Added to that is all the indexing stuff to link the tracks,artists,albums,genres and years together (including track numbers) - that comes to another 400kB for what I had. Still only 60 bytes per track. For a fully functional music server database you'd want file format, duration, volume adjustments, date, etc, but that is still not a lot of data in binary form. The biggest thing, and the thing I've missed here, is the file path, which is probably well over 100 bytes. Still, even there there are simple things that can be done to reduce the storage required, like storing common directories separately and other very simple compression. The point I'm trying to make here is that if you have a cheap and very memory constrained processor, you can still handle an in-memory database of a very large number of tracks in what is a pretty small amount of memory these days if you try. Also, for a Sonos-like system where every node holds a copy of the database, the whole of a millon track database could be synced over the network in a few seconds. Including to smartphone controller apps. So going back to the start of the thread, 64 - 80k track limits are pretty feeble. So now I'm wondering what's actually in the 48MB of my LMS library.db file... utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103488 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Digital Music Systems - track limits!?
probedb wrote: > 100 bytes is nothing though and if the tags are unicode then you just > halved that. 50 characters wouldn't cover the song title + artist for > many of the bands I listen to. I did say well organised. And I still maintain 100 is reasonable as an average - for all those long titles there will plenty of short ones as well. No need to store as full unicode - and the strings are readily compressible if you want. Artist strings and the like shouldn't be stored against every track (and you are doing well if you have a library with a million different artists in it...), and there's little point in storing any tags in the database that aren't there for searching and sorting - if you want to see full tag information on a particular track then just look at the file itself. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103488 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Digital Music Systems - track limits!?
probedb wrote: > It's nice that the SB/LMS system is being kept alive by projects like > piCorePlayer too. I sold my original SB3 and bought a RPi with a > HifiBerry Digi+ board for less money. I see no reason to use a Sonos > player...so expensive in comparison. > > As a programmer the only reason for these limits I can see are hardware > and if the database is indeed kept on each player that's probably why. Agree it is almost certainly a player memory size limitation - the database is probably held in ram. Plus the use of 16-bit track references. It's instructive to have a feel for how much memory you actually need. I would have thought 100 bytes average for per-track tag information would be plenty of allowance. That is only 6MB for 64K tracks, a pathetically small amount these days. In other words, if the player contained something like a raspberry pi with 512M of memory, it should easily be able to hold all the tag information for a million tracks in a well organised in-memory database. A decent sized artwork cache is another matter though. utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103488 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
