Jump to content

gahabana

  • Posts

    48
  • Joined

  • Last visited

  • Country

    Thailand

Retained

  • Member Title
    Newbie

Recent Profile Visitors

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

  1. hi @allo.com, there is noone who can seem to get USB 3.0 adapter provided by Allo to work reliably on USB 3.0 port not a big deal - USB 2.0 port works fine at gigabit speeds. but would be great to know how in your testing it worked and yet on my setup (dietpi 6.9 - allo.com image) it dies very quickly. Most importantly - it is easy to add many DACs to kernel - could you point out to instructions how to build a kernel (for some DACs it is complex but for many just adding USB-ID one line needed in source code)... Thank you !!!
  2. hi @luisma , have been using same setup as you now (Gigabit USB 3.0 ethernet adapter on USB 2.0 port) with Pro-ject S2 Pre DAC. Has been streaming 768kHz/705.4 PCM and DSD512 for over 15 hours with no issues. root@DietPi:~# cat /DietPi/uEnv.txt uenvcmd=setenv os_type linux; bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay console=tty0 loglevel=1 real_rootflag=rw isolcpus=2,3 root=/dev/mmcblk0p2 rootwait init=/lib/systemd/systemd aotg.urb_fix=1 aotg.aotg1_speed=0 the ONLY thing i think i have changed from defaults is adding "isolcpus=2,3" as that allows me to put all the regular workload on 2 cores (roon and/or squeezelite) and have one cpu core dedicated to interrupts coming from network (in this case USB 3.0 Gigabit adapter) and last core dedicated to USB 2.0 pushing data to DAC.
  3. hi, yes am aware. I do have USBridge with Allo Sparky. But it's SW support is somewhat limited, community tiny or non-existant. e.g. USB 3.0 Gigabit adapters do not work on USB3.0 Sparky port. Only on 2.0. Reson is old kernel, nothing else (v3) ... On the other side Sparky (according to Allo) is compatible with Raspberry HAT and those GPIO PINs migjht be the same ... so I thought maybe it would work on Raspberry PI. I have Sparku, Odroid C2, Odroid XU4, NanoPi Neo but none of those is compatible with Raspberry HATs ... i dont want to buy Raspberry PI 3 just to test it out, but if someone has one they could try ?
  4. has anyone tried to run USBridge on Raspbery PI ? thank you
  5. hi @rahul_kc , PM sent. yes with USB 2.0 port it seems to work just fine. But the only reason why i would want USB 3.0 Gigabit adapter is to have it on 10 times faster USB3.0 port - which is one of Sparky's+USBridge selling points In addition when i ran 'iperf' on USB 2.0 it did go up to 250mbit/sec but Roon endpoint stop receiving ... no ability to restart it except reboot. Anyhow, I assume if it works on USB 2.0 port and it's USB 3.0 adapter - we now know it does work just need to figure out how to make it work on USB 3.0 port tx!
  6. btw, regular ethernet (not USB Gigabit as that one stops working before i can diagnose anything) produces this when you look at output of 'dmesg -T' [Sun Jun 10 21:56:24 2018] read phy reg-4 [Sun Jun 10 21:56:24 2018] read phy reg-0 [Sun Jun 10 21:56:24 2018] read phy reg-5 [Sun Jun 10 21:58:29 2018] read phy reg-4 [Sun Jun 10 21:58:29 2018] read phy reg-0 [Sun Jun 10 21:58:29 2018] read phy reg-5 [Sun Jun 10 22:00:31 2018] read phy reg-4 [Sun Jun 10 22:00:31 2018] read phy reg-0 [Sun Jun 10 22:00:31 2018] read phy reg-5 [Sun Jun 10 22:02:31 2018] read phy reg-4 [Sun Jun 10 22:02:31 2018] read phy reg-0 [Sun Jun 10 22:02:31 2018] read phy reg-5 [Sun Jun 10 22:04:14 2018] TX ERROR status: 0x007e0000 [Sun Jun 10 22:04:33 2018] read phy reg-4 [Sun Jun 10 22:04:33 2018] read phy reg-0 [Sun Jun 10 22:04:33 2018] read phy reg-5 [Sun Jun 10 22:06:33 2018] read phy reg-4 [Sun Jun 10 22:06:33 2018] read phy reg-0 [Sun Jun 10 22:06:33 2018] read phy reg-5 [Sun Jun 10 22:08:40 2018] read phy reg-4 [Sun Jun 10 22:08:40 2018] read phy reg-0 [Sun Jun 10 22:08:40 2018] read phy reg-5 [Sun Jun 10 22:10:40 2018] read phy reg-4 [Sun Jun 10 22:10:40 2018] read phy reg-0 [Sun Jun 10 22:10:40 2018] read phy reg-5
  7. hi , I purchased 2 weeks ago from Allo.com Sparky / USBridge combo with Allo's provide Gigabit USB Ethernet adapter. When using regular ethernet (on board) which is 100mbit it seems to be working okey. Some messages in 'dmesg' output and from time to time i get msg 'TX Error' . When I connect USB GIgabit adapter lights on the adapter start blinking and it does get IP address. After about 30-45 seconds it stops working (can not be pinged). I tried adapter on Macos and it works just fine so it does not appear to be HW problem. In order to determine what might be the issue i tried to connect BOTH adapters and login on 100mbit one via SSH but dietpi config seems to activate only one adapter ... so not sure how to do problem diagnoses but net is - Allo's sells configuration that they have tested and it has to work (i assume they did test it). I am loading Allo's supported DIetpi. Tried re-flashing MMC card as well as SD-card only to make sure that is not the root cause but it is not. Dietpi was 6.6, then 6.8 then since 2 days ago 6.9 but behavior has not improved. My guess is linux kernel has not been tested with adapter that they sell. As Allo is monitoring this forum as only means for their clients to get support - hopefully they can respond with suggestions on how to fix the issue or at least how to do problem determination. Thanks in advance !!!
  8. @left channel & @Fella55 - i agree - the ONLY benefit of native DSD vs DSDviaDoP is that DoP uses little bit more USB bandwidth then native mode. So the only downside is (until firmware has fixed the Native DSD64 bug after PCM44.1 or 176.4kHz) is that you can not use DSD512 via DoP ... and have to do it native. And if you do that all the time (upsampling to Native DSD512) - firmware bug is not obvios as with DSD128/256/512 there is no hiss/static problems. So kinda very irritating and obviouslty a flaw, but for 99% situations, it is avoidable.
  9. hi @Fella55, as for DSD playback problems - yes, it is a firmware bug. You are using DSD Native ... DSD128 or 256 or 512 do not have that problem and even DSD64 only when switching from 44.1PCM to DSD64 and from 176.4kHz PCM to DSD64. Workaround is to use DSD via DoP. Yes will use bit more USB bandwidth to talk to DAC but apart from that no big deal. And in that case you will max out at DSD256 can not do DSD512 via DOP. ... or you leave DSD Native and upsample all DSD content (via custom upsampler config in Roon) from DSD64 toi DSD128. would be nice if Project could be bothered to update the firmware. ps. these issues do not happen when one is using Windows drivers and on Mac DSD Native is not supported anyhow,
  10. hi @franz159 , not sure if it is my english - i think pops/clicks have disappeared completely if one is using firmware that was posted over month ago. DSD all the way to 256 via DoP and 512/NativeDSD on Windows and PCM in all scenarios (incl. linux) have no pops/clicks at all. The only scenario where it may happen if you are using linux and have one of that latest kernels that recognises S2 as having Native DSD support and you do not upsample everything to DSD512 or DSD256 ... then you do get issues when switching (and only in that scenario) from PCM 44.1 or PCM 176.4 to DSD64. That's it. And if one wants to have that scenario then use DSD via DoP and no issues whatsoever.
  11. No, but if you set the volume to 0db (Max) on the DAC and do not change it via remote - it will be fixed.
  12. spot-on @left channel ... ive read threads how people concluded that CD ripped into PCM/WAV and/or compressed into lossless format called FLAC sound differently ... even when player/endpoint was not doing any conversion (cause it happened on the server) ... and yes, the only technical difference in reality between dop and native dsd is that DoP packs 16bit of DSD signal into 32 bit that go into DAC it does need more bandwidth to USB DAC then Native ... DSD64 via DOP uses same bandwidth as PCM176khz and DSD64 fits into PCM88.4kHz (32bits). Anyhow, for DAC electronics to say - if i get signal which is DSD packed into DOP drop 16 bits is not really 'compute intenstive'.
  13. just tested Windows. Installed latest drivers from Pro-ject website for Windows under Win10. Went into Roon, said endpoint (running those windows 10) should use ASIO. all sample rates/frequencies showed up (768kHz and DSD512) and I could choose "DSD Native' as mode for DSD. Then I tried upsampling all content in Roon to DSD512. Played flawless. Tried MQA as well (w/o upsampling to DSD) - no more hickups. Didn't bother trying WASAP, ASIO seems to work perfectly fine in all scenarios. In addition unlike Linux, when using DSD Native (64, 128 or whatever source is) - there are no clicks nor hiss after it switches from PCM to DSD. On Linux one has to use DSD DoP to avoid those problems. So my testing/conclusion is: if you use Windows 10 all works well. PCM, DSD via DOP (up to 256), MQA and DSD Native (up to 512). No pops/clicks in any scenario. If you use Linux almost all is the same as above with exception noise at start after using DSD in Native mode (Dop is fine) when source changes from PCM44.1 to DSD64. I have already complaigned on pinkfishmedia about that but not sure if anyone really cares as 80% of the people use windows and rest either Mac Or Linux. Even as it is - it sounds great and is one of the most versatile DACs esp with USB/computer sources ! my 2 cents
  14. hi @Em2016, since 2 months most recent Liinux kernels (4.9 and later and even 4.4) have been updated. it is ONE line in Linux Kernel source ... file to be patched is under 'sound/usb/quirks.c' https://github.com/torvalds/linux/blob/master/sound/usb/quirks.c line #1351 https://github.com/torvalds/linux/blob/master/sound/usb/quirks.c#L1351 it was added just after Oppo HA-1
  15. Native DSD support. hi all - Native DSD support works (all the way to DSD512) on Linux endpoints. Roon recognizes it just fine. See below (all the way to PCM 768khz). You do need one of the distributions which had updates in last 2 months (or recompile your kernel with adding one line) for DSD512 otherwise you need to use DoP and then it goes only to DSD256. PCM is fine either way all the way to 768kHz. Having said that - there are still two issues that I have when using DSD Native mode - pops/clicks that have been removed with 2.12 Firmware upgrade work perfectly with PCM and DSD via DoP, but they show up when using Native DSD. Not as consistent as it was before FW upgrade, but they still do from time to time. - And worse when switching from PCM 44.1 to DSD64 (in Native mode) often in 1st 2 seconds there is hiss/noise that takes about 3-8 seconds to 'clear-out'. If all you need is to have your entire content upsampled to native DSD512 or 256 it will work fine all the time as switching between PCM and DSD does not happen. @MikeRock & @Em2016 , am curious if you have tested that scenario (DSD128/256/512 do NOT suffer from hiss/noise but but plain/simple DSD64 does after PCM - 50% of the time) - could you check that on your setup ?
×
×
  • Create New...