Jump to content

cat6man

Members
  • Content Count

    459
  • Joined

  • Last visited

About cat6man

  • Rank
    Freshman Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. so if these buffers are all at the endpoint running squeezelite, are there any LMS buffer settings at the server? i see you can buffer radio from 3-30s, so there is something inherently there to buffer inputs. option B would seem to be to run squeezelite on the same NUC as the server, implementing the larger buffers since I have 8G of ram, and run a monoprice slimrun USB to my DAC
  2. thanks Piero! i saw the new option but didn't recognize the significance. i'll follow up on the AL thread if i have any questions.
  3. sonore does not expose the config file, but do provide web access to a squeezelite settings page on the Rendu where you can change what look like the -a parameters. they recommend not changing the (unknown value) default. as for buffer size possible, i'm sure it is far smaller than what you guys did with a NUC as the endpoint........now i have that to consider, hmmmm..................has anyone done a direct comparison of a Rendu vs. a NUC endpoint, using a separate server box? as for Rendu buffer available, if I can do 500ms of buffering in the Rendu/NAA with hqplayer, that would suggest for red book (44.1k) x (16 bits) x (2channels) x (1/2s) x (1byte/8bits) = 88.2KBytes which is more than an order of magnitude smaller
  4. thanks again, i'm sorry i'm not being sufficiently clear with my question. i've seen the earlier post. what i mean to ask is, 'where are the buffers located, at the server or at the endpoint?' both the -b and -a buffers are set in the sqeezelite.conf file which resides on the server. are either of those buffers implemented at the endpoint (the opticalRendu in my case). the Rendu has the following squeezelite settings available: Buffer size (buffer time in ms) Period count (period count in bytes) since these look like the -a parameters, i'm wondering if they are the same as the -a parameters set in the config file as a comparison, for hqplayer there is a buffer setting (in ms) that is implemented in the NAA (i.e. the Rendu)
  5. thanks for the clarification. do you have any suggestions as to buffer size without roon core? did you ever compare root core server with LMS? and to clarify on my part--i never requested support from euphony so they did not fail to support me. my view is that stuff should work (it's the engineer in me--'we don't need no stinking manuals') it didn't, and i found the interface very confusing anyone know where these buffers reside in h/w or how large they can be made?
  6. resurrecting a path that's a bit old. i have audio-linux running on a nuc, streaming to an opticalRendu i've been using hqplayerd for a few years now with all processing turned off and found that moving the renderer off of the Rendu (just NAA) made a nice improvement, though most users use hqplayerd for upsampling/etc. i recently upgraded my networking (ubitquiti edgerouterX to isolate streams related to audio) and power supplies all over the place (plus many many fewer wall warts) so i thought i would revisit some previous assumptions. a long time ago, i started streaming with logitech music server, on a ubuntu based nuc, streaming to a logitech touch with digital usb out to my DAC.......come a long way since then previous, but recent, conclusions: hqplayerd in ramroot on AL is really good with "older" AL builds (e.g. 140) and this sounds much better than the same configuration on build 250........who knows why so, i decided to go back and revisit logitech/squeezelite and running on build 250 was meh running on USB but was outstanding running in ramroot, definitely competitive with hqplayerd on 140 (i need a lot more time to do more detailed comparisons).......hmm, what is going on here? now my old experience with squeezelite had been without AL or ramroot, but together this is a contender. next questions: would squeezelite on AL build 140 be even better? i don't know as i'm having trouble getting the LMS server to install.........stay tuned the above observations was made with the default buffering for squeezelite. i next tried -b 2097152:2097152 -a 52428800:4:: in the config file and it sounded good (but different).....again, i apologize for not having more detailed observations yet...........i had expected, based on the above, to have glitches or other problems but i have seen none whatsoever. therefore, why not keep increasing the buffers further and see where that road leads? i have 8G ram so i'm going to try doubling the ~2G input/output buffers and do some serious listening comparisons. one thing i don't understand is where these buffers reside? are the input/output buffers (parameter -b) on the NUC? what about the 52G -a buffer? is that on the opticalRendu? as a comparison i have set the opticalRendu buffer for hqplayer to 500ms and this has improved the sound. i also assume that if i had a nuc instead of the opticalRendu, i would have much more flexibility to buffer at the renderer side. cheers (and stay safe everyone) p.s. i've ended my euphony experiment after much wasted time and frustration trying to get external disk music played from memory.......in general i found the design/layout confusing.........my trial ran out as i ran out of patience
  7. Very nice work Chris. Do you plan to do any listening comparisons (or have I missed it)? How does it compare to a simple NUC server with a good power supply (HDPlex or better) streaming to something like an ultraRendu? There is a lot of space between that and a Taiko extreme. I think a lot of us want to know where your design falls in that range.........and only you have one!
  8. i wonder if the benefits heard under DAC and power supply are also observed with headphones, as well as with your speakers? this would give us an indication of whether the mechanism is immunity from the outside (i.e. the speakers setting the room ablaze with impulses) or removing inherent resonances/etc that originate in the electronics
  9. just found updated euphony trial download package...........i'll retest with latest euphony to see if any conclusions are changed
  10. may not be your problem but i found it needs to be plugged in deeply on some devices.........insufficient contact observed here until i pushed it in further on the NUC
  11. thanks. i do not, however, have a bridge configured, and i connect the server and NAA via an edge router (ubiquiti edgerouterX SFP). the edgerouter segregates my music from all the other digital traffic so its only inputs are ethernet copper to audiolinux NUC, ethernet copper to NAA and optical SFP to fios router (for wifi to hqpd controller and for streaming/qobuz) any suggestions for ethernet priority in my case? should it have a higher priority compared with the other interrupts? relative to USB/HDD? any downside if i change RTIRQ_NAME_LIST="usb" to RTIRQ_NAME_LIST="en01" or RTIRQ_NAME_LIST="en01 usb"
  12. hi folks, i'm running hqplayer in ramroot node in a NUC server, music is on hdd attached to the NUC via usb. streaming is over my home network to an opticalRendu running as an NAA. so the NUC has two critical things to manage/prioritize 1. ethernet streaming to NAA 2. music input from usb attached HDD i've attached the files that give my RTIRQ and RTAPP configurations. it seems the usb (IRQ#126) has a high priority but not the ethernet (IRQ#127, i think) what lines of code in the config files should i consider changing here? has anyone here specifically experimented with priorities and streaming to an NAA? RTparams.txt
  13. other config/setup details: NUC running music server using external usb HDD, both powered by hdplex200. planned tests: 1. hdplex200 to be replaced by hdplex300 (end of week?), hdplex200 moves to basement to replace a bunch of wallwarts on my sagetv video server 2. monoprice slimrun usb has arrived. to be inserted between HDD and NUC and powered separately by hdplex edit: adding RTparameters info. i assume that i want priority to be given to the ethernet connection(to stream audio to NAA) and to the USB (to get music from the HDD)..........should ethernet streaming to NAA be a higher priority than USB receiving music from HDD? i assume that irq#126 is the usb. which IRQ is for the ethernet that streams to the NAA? is it irq#127? RTparams.txt
×
×
  • Create New...