Jump to content

rmpfyf

Members
  • Content count

    1,078
  • Joined

  • Last visited

About rmpfyf

  • Rank
    1000+ Post Club

Profile Fields

  • Location
    Online
  • Country
    Earth

Recent Profile Visitors

2,232 profile views
  1. XMOS-based Asynchronous USB to I2S interface

    Clay, I wouldn't think the 216 offers significant improvement unless you're running out of MIPS, RAM, IO or other; the 216 is essentially two 208's. I'd think the real magic in these things is in isolation, power and reclocking... the last part is significantly understated. There are certainly a few boards out there doing logic-based reclocking that allegedly sound quite good. You'd have to wonder what licensing an Amanero or similar - something already having the driver done - and building the rest would be worth.
  2. XMOS-based Asynchronous USB to I2S interface

    Clay IMHO there's a few good boards out there and a lot of stuff that's poorly/not completely done or overpriced. I get what you're looking for, maybe an easier way concerns reviewing a few different parts? I don't think it should be a surprise that the Amanero isn't TOTL, it's not intended to be. There are a few good USB>I2S implementations out there, though.
  3. electric cars

    Ease up - takes a lot of work to get that far. Should've painted it bronze IMHO - has echoes of the Holden Hurricane.
  4. Used to own one of these (prefer the ST/VT60's, though this is a very excellent TV... and something of a steal at $700). Would suggest the ad gets amended a little to remove the Skype reference: it's been over a year since Skype for TV was discontinued, and Samsung has pulled it from their repositories (e.g. if not done already the next update will delete Skype - which was a shame, it worked very very well on this TV). Would add to the OP that parts for these are plentiful and not expensive at all, and that it's possible with a few commands you'd find online to have the TV believe it's in another country, and to bring up a default app selection from another region (nice for all the VPN freaks here, and not something you can do with every TV on the market). If I was in NSW I'd buy this for a family member in a heartbeat. Excellent TV and a ridiculously low price. GLWTS.
  5. Glad to hear - they're almost the same as my settings, though many here find a different path works Try the RAM as fast as you can (1600MHz or 2400MHz); see how that sounds. Always an overhead with a swtich, unless you grab priority. You can grab priority
  6. I'm going to explain some stuff which will seem weird coming off Windows, but don't worry, at worst we can find some time and help out maybe in person. Increasing priority needs to be done with some forethought. Some tuners - PeterSt of Phasure DAC fame - reckons you need as many cores as possible to ensure that the one core doing audio doesn't get interrupted with anything else. In Linux I do it the other way around - I boot the system with reserved cores (which means 'don't use these unless it gets super extreme') and then play audio on a different core. This is a lot cheaper (a 4-core CPU is plenty, though you'll want cache) and more possible in Linux because I can play music - complete with network access and a NFS client to read files on my NAS - with not more than 15 processes, the majority of which are sleeping during playback (doing the same in Windows is nearly impossible). Naturally assuming you have hyperthreading disabled in BIOS and you've had a play with C-states enough to have settled on something that works for you (stop me here if not). So to reserve cores you need to add the following to the kernel boot parameters: isolcpus=x,y,z Where x,y,z are the CPU kernels you don't want the computer to use. You will also want to compile the kernel without the multicore scheduler, e.g. without the bit of software that says 'hmm, I need to do something, now let me think about how I break this up among the CPU cores I have at my disposal here'. This will give you a system that is fast and responsive to most tasks for an audio PC without high and variable latency in thinking about what comes next. Then to run anything on a particular core you use the taskset command, which is part of the utils-linux package. e.g. taskset <COREMASK> <PROGRAM NAME>, where coremask is the CPU (or CPUs) you want to launch something on, and program name is the executable path to that program. You will want to give whatever launches that program superuser privileges, which are required to manipulate system calls of this nature. You will also find (get this) that your audio will sound different depending on which core you play it on. This is in part because the physical difference between the cores differs, and whilst one is your player and only your player, your audio devices are running off another, and the difference in latency is often audible. So play around. Increasing priority can be done with the nice command, though if you're using a Linux distribution and have the real-time kernel installed (I assume you do) then against, the utils-linux package has the chrt command which allows you to manipulate the real-time priority of any process (as launched or when running). This isn't limited to the player for your device, but also the processes tied to music-relevant interrupt requests ('hardware says ship a few more bytes of music.... now!'). It requires a bit of tweaking. SnakeOil OS from memory has a screen that allows you to tweak a few of these, though setting everything at realtime (priority=99) can grind your computer to a halt occasionally as it deals with stuff it's been told to deal with right now with no excuses. Other stuff you'd do? Heaps! Setup a RAM disk and script your players to run through that if not doing it already Delete your swap partition or file (depends which vers Linux, some use a file, most a partition) if not done already Set your clock sources and frequencies correctly Optimise system component frequencies Power down all unneeded USB (mentioned this a few posts up) Remove unnecessary processes (there are many), including removing DHCP and running a static IP Reserve a core for DRC and run that if you like Many more Welcome to Linux!
  7. electric cars

    ChargePoint's been invested in a number of times in similar timeframes. Shell Technology Ventures has deep pockets though I think the restriction is more on their side; they tend to invest in lower amounts and CP would have cost a great deal more. DC-fast charging at Autogrill-type locations gets us over the perceptual hump, real adoption requires destination charging, or at least greater frequency of charging. Not everyone has access to home charging. Theres some serious coin to be made in destination charging networks IMHO.
  8. Renault Zoe

    Not least because the profit margins on either car are not likely to be identical.
  9. electric cars

    Sure... though that'll change quickly. Possibly... though that'd be a reason to purchase ChargePoint and not NewMotion - DC-fast takes either engineering resources to develop internally, not something NewMotion has in spades. At any rate I'd not think charging and traditional servos to be a match in the EU (unless we're talking Autogrill-type road stops). Destination charging is more where it's at; having electrons in the mix for work vehicles (e.g. think fuel card) is lucrative business for the large petrochems. Would suggest the investment might be initially pointed there. It's a small investment at any rate and nothing precludes Shell from investing in CP or other tech vendors and service providers in the space.
  10. Kodi v Jriver

    Kodi doesn't get the attention it deserves. Recent versions are actually a damn good music player, and you can customise too, or run it as a front end for other things.
  11. It's moved from storage to my study Someone has my TX1 dev board, I'll try flash Ubuntu onto my shield instead.
  12. Found something that moved SQ forwards a notch on mine, thought I'd share. I'm no USB fan and I don't have a fancy audiophile USB hub... mostly because I'm cheap (no disrespect to those that do have 'em). I get by with having only my DAC's Amanero plugged into the motherboard's USB. A motherboard typically has multiple USB hubs and ports which, of course, are all powered on at boot. It is possible in many cases to power them off, however, and only leave powered that which you need on for music output. Linux users might want to check out https://github.com/mvp/uhubctl/blob/master/README.md - straightforwards to use and compile - does the trick well. Sounds better in blind tests too, here at least. (EDIT: Bl***y hell it really does sound rather much better.)
  13. @mwhouston pics of the actual article added. Apols for delay.
×