Not sure what you mean about doubling or tripling USB speed? USB speed is fixed at USB2 (480Mbps) on Pi2 and 3, but in the real world, ~200-250Mbps.
No, I'm not feeding..... I have submitted a bugfix to the RPi github for the 4.7.y, for one specific issue.
It's up to them whether they accept it or not.You are not going to see either the 384k, ES9023, or simple framework patches in an official kernel, unless someone else is responsible for getting it accepted. (I simply do not have time to run around in ever decreasing circles, or the desire to butt head with brick wall.) When I'm allowed to drop the code in a couple of weeks for the AK44XX series, I probably wont even try to upstream or downstream it. That will be left to one of the manufacturers that is going to be shipping an AK44XX design board/HAT. I suspect there will be at least 3 between now and Christmas.
The journey was fun, even if the destination left a little to be desired........
Understood.
Hi @soundcheck, yep have one I use on a pi A+, for kali/piano testing, and by coincidence a few people were trying to get them to work with piCorePlayer... so I revisited it
-->Announce: piCorePlayer 3.00 - Page 47
However, re: the pZERO... now that I can compile, play with clives 4.4.simple kernel etc... the piZero can handle 384K easily over wireless, it needs a sustained ~19Mpbs ... it can handle the upsampling LMS side (squeezelite -W), or pi side (-R X) --> it's a non-issue.
Sooo gigabit's useful to stuff a large (audio) RAM buffer in as little time as possible, or Video (OSMC)... a native bluray image needs a little extra, and I process the DTSMA --> 2.0 channel LPCM (this is big)... to run lossless MA into my DAC... can't do it (comfortably over 100Mps, there are stalls here & there) without Gigabit!
Last edited:
I did this that night... works perfectly 384K on the D+PRO slave or master (no more weird 352K only & pegged CPU, easily does 384K at ~28% cpu, or less if you upsample w/LMS), and works fine on the piano with your new overlay (of course without the Kali... dead air 352/384)
Last edited:
Good, good, good.....
Didn't they send you a new kali with the updated firmware that can output 352k4/384k and fixes the 16bit issues? Mine arrived earlier this week.
Hi @soundcheck, yep have one I use on a pi A+, for kali/piano testing, and by coincidence a few people were trying to get them to work with piCorePlayer... so I revisited it
Announce: piCorePlayer 3.00 - Page 47
However, re: the pZERO... now that I can compile, play with clives 4.4.simple kernel etc... the piZero can handle 384K easily over wireless, it needs a sustained ~19Mpbs ... it can handle the upsampling LMS side (squeezelite -W), or pi side (-R X) --> it's a non-issue.
Sooo gigabit's useful to stuff a large (audio) RAM buffer in as little time as possible, or Video (OSMC)... a native bluray image needs a little extra, and I process the DTSMA --> 2.0 channel LPCM (this is big)... to run lossless MA into my DAC... can't do it (comfortably over 100Mps, there are stalls here & there) without Gigabit!
I received my Realtek 8153 based 10€ device yesterday.
Interesting your Anker comes with the same chip.
I had to activate the module in the kernel first. My stripped down kernel has basically all stuff turned off.
Arch Linux seems to be a bit more tricky to get the 2nd interface and related network routing going.
Right now I'm as far as ifconfig showing me that eth1 is there. (Like your screenshot over at squeezeforums). However I didn't manage last night to get DHCP respectively traffic going. I'll try today.
As you know, I run bulkload mode/rambuffer playback mode since years. I do not
know if a peekload over a period of 2s or 4s will make a such a big difference.
There a two more potential tuning steps I have in mind while going that path.
1. Turn off the onboard ethernet
2. Externally powering the ethernet dongle.
######
@Clive
Have u tried the Kali with the Mambo?? If so. Does it make sense to get one? (Because u might experienced a huge impact)
Last edited:
No, but I suspect with ES9023, you will gain more, if you use the MCLK from kali (SYNC) and disable on-board Mambo OSC (ASYNC). I think Greg may have already tried that. (ISTR, he's not a fan of Sabre ASRC.)
Just made my 10€ USB3 GBIT ethernet dongle based on Realtek 8153 on my PI2 under ARCH Linux run.
I ran some performance tests.
TCP Performance:
UDP Performance (LMS and squeezeclients make use of UDP)
Not bad. Much better then expected. Especially on the PI2.
Basically a network performance boost of 300% and no data lost.
BTW:
@384kHz - LMS resampled - I'm running a CPU load of 5.9% (after the inital peek load period) - ckramer 28% ??? PI2/PI3 ???
I ran some performance tests.
TCP Performance:
Code:
root@xxx ~ # iperf3 -c 192.168.1.20
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.24 port 59722 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 36.9 MBytes 309 Mbits/sec 0 187 KBytes
[ 4] 1.00-2.00 sec 35.8 MBytes 301 Mbits/sec 0 187 KBytes
[ 4] 2.00-3.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 3.00-4.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 4.00-5.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 5.00-6.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 6.00-7.00 sec 35.8 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 7.00-8.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 8.00-9.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
[ 4] 9.00-10.00 sec 35.9 MBytes 301 Mbits/sec 0 197 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 360 MBytes 302 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 359 MBytes 301 Mbits/sec receiver
iperf Done.UDP Performance (LMS and squeezeclients make use of UDP)
Code:
root@xxx ~ # iperf3 -c 192.168.1.20 -u -b 1000M
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.24 port 41691 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 34.7 MBytes 291 Mbits/sec 4444
[ 4] 1.00-2.00 sec 34.6 MBytes 290 Mbits/sec 4433
[ 4] 2.00-3.00 sec 34.6 MBytes 291 Mbits/sec 4435
[ 4] 3.00-4.00 sec 34.7 MBytes 291 Mbits/sec 4437
[ 4] 4.00-5.00 sec 34.6 MBytes 291 Mbits/sec 4434
[ 4] 5.00-6.00 sec 34.7 MBytes 291 Mbits/sec 4437
[ 4] 6.00-7.00 sec 34.7 MBytes 291 Mbits/sec 4436
[ 4] 7.00-8.00 sec 34.6 MBytes 291 Mbits/sec 4435
[ 4] 8.00-9.00 sec 34.6 MBytes 291 Mbits/sec 4433
[ 4] 9.00-10.00 sec 34.6 MBytes 291 Mbits/sec 4434
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 347 MBytes 291 Mbits/sec 0.139 ms 0/44352 (0%)
[ 4] Sent 44352 datagrams
iperf Done.Not bad. Much better then expected. Especially on the PI2.
Basically a network performance boost of 300% and no data lost.
BTW:
@384kHz - LMS resampled - I'm running a CPU load of 5.9% (after the inital peek load period) - ckramer 28% ??? PI2/PI3 ???
Code:
307 squeeze+ -2 -10 633.6m 630.2m 5.9 64.7 0:15.92 S squeezelite
Last edited:
Why? When the piZERO is perfect
see the pic:
post #7: Allo KALI Reclocker & Raspberry Pi DACs running as Slave or Master?
Attachments
Last edited:
Here's where I'm at as of now...
Raspberry Pi3
1 - My Raspberry Pi3 is running Moode 3.1 with on-board wifi and configured with as static IP address, my router being set to channel 10. Other software has been tried but my opinion is that Moode Audio sounds best. My local group of audio friends also agree - Moode Audio sounds best. In fact, all of the following selections and/or comparisons that I have made have been verified by this very same group.
Getting the wifi working with the HiFi Berry DAC + Pro is really a struggle, even with a wifi dongle; but, once the network was set to use channel 10, it works well - even with the on-board wifi. This is because the local oscillators on the HiFi Berry DAC + Pro interfere with the wifi signaling on channels 1, 6, 11 and 14, see: https://www.tablix.org/~avian/blog/archives/2016/12/hifiberry_and_wi_fi_interference/ Thus, it is best to avoid those channels by avoiding automatic channel selection by the router and selecting another channel, for example, I choose channel 10.
2 - Power for the Raspberry Pi3 is feed into GPIO header pins 2 and 6, see https://pinout.xyz, bypassing the protection circuitry after the micro usb connection comprised of a current mirror, etc. shown in the upper left hand corner here: https://www.raspberrypi.org/documen.../schematics/RPI-3B-V1_2-SCHEMATIC-REDUCED.pdf Somewhat surprisingly, this is a pretty nice upgrade over powering via the micro usb connector. Others have found the same, albeit in a little different configuration.
3 - Power to the Raspberry Pi3 is from a 5 volt, 2.5 Amp, micro usb, switch mode wallwart, see: QVS 2.5Amp 5.1v Switching Power Supply for Raspberry Pi B with Built-in 4ft Micro-USB Cable ARUSB-2.5A - Micro Center
Before you laugh and dismiss what I’m about to say, just because it is a SMPS, here’s what has been tried in terms of linear supplies. Both of the later mentioned DIYINHK regulator boards, a garden variety LM317 implementation, a discrete high speed wide bandwidth linear regulator of my own design loosely based on some work I did with John Swenson, a huge HP lab supply weighing more than 35 pounds and another more generic adjustable linear supply. In every case, the little wallwart won out sonically - and not by a small margin.
Why might that be? Well, and this is true of all computers, it turns out that the Raspberry Pi3 load fluctuates wildly. For instance, on one of the aforementioned linear supplies that has a digital read out for current, the current varied any where from a couple tenths of an amp to over 2 amps. I know this isn’t exactly accurate but, it give you some idea of what is happening. Further, two of these linear supplies have the ability to set an upper current limit, It wasn’t until the current limit was set to over 2.5 amps that the supplies worked for the Raspberry Pi3.
I am using a bus power USB Hard Drive.
Still, computer loads vary wildly and are very dynamic in nature. Practically, SMPS are better suited than their linear counterparts in dealing with this.
Again, the sonic differences here were not subtle.
4 - Pins 1 and 17 in the GPIO header are bent over so that 3.3v does not pass from the Raspberry Pi3 to the HiFi Berry DAC + Pro.
HiFi Berry DAC + Pro
The HiFi Berry DAC + Pro’s claim to fame, if there is one, is the ability to run the PCM5122 off local on-board oscillators rather than running the PCM5122 in PLL off the clocking provided through the GPIO by the Raspberry Pi. We all know the oscillator frequency of the Raspberry Pi is not an integer multiple of a sample rate frequency, see: The Raspberry Pi: Audio out through I2S | Dimdim's Blog, so this must be done to have any hope of a low jitter signal.
I did run a PCM5102A in PLL mode in comparison to the HiFi Barry DAC + Pro, and if you know what lower jitter sounds like - this is it. The sonic advantage is clear. I applaud HiFi Berry for being the first to do this in a Pi HAT. It is the reason I bought it. And, I’m still glad I did - in spite of the wifi frustrations which I feel now are basically moot.
Before we get into what I did to the HiFi Berry DAC + Pro let me say, I’m a TI/BB DAC chip fan, have been for a long time. I’ve tried many others, one of which is the ESS brand. I know there are HAT DACs using the ESS chip(s) with their own oscillators but I always hear the ASRC in those designs.
The secret to getting good sound from the PCM51XX series lies in the implementation and, more so, to the supplies. Here’s what I did.
1 - I used WBT Nextgen RCA jacks. This is a no brainer in my opinion and makes a noticeable difference. I caution anyone against removing the RCA jacks on the HiFi Berry DAC + Pro. The traces from the PCM5122 output filter to the through hole solder connections provided for adding your own RCA jacks is quite thin and goes under the on-board jacks. Frankly, I think HiFi Berry could have done a bit better job here with this trace work. You’ve been warned.
2 - I changed the caps (C7, C8) in the LPF after the PCM5122 to PPS caps, Digikey P/N PCF1457CT-ND as suggested by Greg Stewart. Generally, I have found over more than a decade of messing with DACs that more often than not, you’re better off without these LPFs. But, not in this case. Changing to this type of cap (PPS) is a definite improvement.
3 - I also did the other capacitor changes suggested by Greg; but, once you’ve done the supply changes below, their efficacy is reduced.
4 - For the PCM5122 analog supply, I removed the 0 ohm resistor (R14) and the on-board 5 to 3.3V regulator (U2), bridging across the input and output pin land areas, and feed 3.3V into P3. The regulator in the supply is the TI TPS7A4700, see: 4.17uV Ultralow noise DAC power supply regulator 3.3V/5V 1Ax2 - DIYINHK I’ve found over time that I prefer TI regulators with the analog section of Ti DAC chips - go figure… If you want to leave the on-board regulator and feed 5 volts in, you can do that; but, it is a little better without U2. Kind of a trade off between the regulator being proximate the load and having a better regulator.
For completeness, a garden variety LM317 based, a discrete current sourced, shunt regulated, and several other of the latest generation series type regulators were compared here. The TPS7A4700 won out.
5 - For the PCM5122 digital section and the clocks, having bent pins 1 and 17 over in the GPIO header, I put a white wire jumper between GPIO extension header through holes 1 and 17 and feed 3.3V into vias 17 (+3.3v) and 20 (GND). The supply is based on the LT3042 with a pass element for additional current handling and has a common-mode choke on the input, see: 0.8uV Ultralow noise DAC power supply regulator 3.3/5/7V 1.5A*x2 - DIYINHK The notion here was to provide the wildly varying peak peak current demands associated with processing while prevent any noise from making its way in or out of what was being supplied.
I did try separate supplies for the digital section of the PCM5122 and the clocks; but, frankly, there wasn’t enough difference to make it worth the trouble.
Again, for completeness, a number of supplies as mentioned herein above were compared; but, this one won out.
6 - For the AC feed to the two above supples, I use a 50VA 6V+6V toroid, having a 4.17 amp rating per winding. I tried lesser rated toroids and E/I based transfomers but the 50vA toroid really made the sound stage much, much better. I was surprised.
Conclusion
Finally, all of the forgoing was mounted to a 7” by 12”, 1/8” thick 6061 aluminum plate. Front and rear panels were fabricated from 1” by 1/2” aluminum channel stock. A lid of correspondingly sized 6061 (not shown) was also made. The difference from mounting everything to the plate may likewise come as a surprise to some; but, I’ve had this happen before. Metal standoffs and rigid often times helps clocks and, in this case, you could sure hear it.
At this point, there’s not a lot else to try. Maybe some galvanic isolation; but, that’s about it.
Hopefully, this inspires others to try something. You just might find that having a USB interface between you computer and your DAC isn’t all it is cracked up to be...
Raspberry Pi3
1 - My Raspberry Pi3 is running Moode 3.1 with on-board wifi and configured with as static IP address, my router being set to channel 10. Other software has been tried but my opinion is that Moode Audio sounds best. My local group of audio friends also agree - Moode Audio sounds best. In fact, all of the following selections and/or comparisons that I have made have been verified by this very same group.
Getting the wifi working with the HiFi Berry DAC + Pro is really a struggle, even with a wifi dongle; but, once the network was set to use channel 10, it works well - even with the on-board wifi. This is because the local oscillators on the HiFi Berry DAC + Pro interfere with the wifi signaling on channels 1, 6, 11 and 14, see: https://www.tablix.org/~avian/blog/archives/2016/12/hifiberry_and_wi_fi_interference/ Thus, it is best to avoid those channels by avoiding automatic channel selection by the router and selecting another channel, for example, I choose channel 10.
2 - Power for the Raspberry Pi3 is feed into GPIO header pins 2 and 6, see https://pinout.xyz, bypassing the protection circuitry after the micro usb connection comprised of a current mirror, etc. shown in the upper left hand corner here: https://www.raspberrypi.org/documen.../schematics/RPI-3B-V1_2-SCHEMATIC-REDUCED.pdf Somewhat surprisingly, this is a pretty nice upgrade over powering via the micro usb connector. Others have found the same, albeit in a little different configuration.
3 - Power to the Raspberry Pi3 is from a 5 volt, 2.5 Amp, micro usb, switch mode wallwart, see: QVS 2.5Amp 5.1v Switching Power Supply for Raspberry Pi B with Built-in 4ft Micro-USB Cable ARUSB-2.5A - Micro Center
Before you laugh and dismiss what I’m about to say, just because it is a SMPS, here’s what has been tried in terms of linear supplies. Both of the later mentioned DIYINHK regulator boards, a garden variety LM317 implementation, a discrete high speed wide bandwidth linear regulator of my own design loosely based on some work I did with John Swenson, a huge HP lab supply weighing more than 35 pounds and another more generic adjustable linear supply. In every case, the little wallwart won out sonically - and not by a small margin.
Why might that be? Well, and this is true of all computers, it turns out that the Raspberry Pi3 load fluctuates wildly. For instance, on one of the aforementioned linear supplies that has a digital read out for current, the current varied any where from a couple tenths of an amp to over 2 amps. I know this isn’t exactly accurate but, it give you some idea of what is happening. Further, two of these linear supplies have the ability to set an upper current limit, It wasn’t until the current limit was set to over 2.5 amps that the supplies worked for the Raspberry Pi3.
I am using a bus power USB Hard Drive.
Still, computer loads vary wildly and are very dynamic in nature. Practically, SMPS are better suited than their linear counterparts in dealing with this.
Again, the sonic differences here were not subtle.
4 - Pins 1 and 17 in the GPIO header are bent over so that 3.3v does not pass from the Raspberry Pi3 to the HiFi Berry DAC + Pro.
HiFi Berry DAC + Pro
The HiFi Berry DAC + Pro’s claim to fame, if there is one, is the ability to run the PCM5122 off local on-board oscillators rather than running the PCM5122 in PLL off the clocking provided through the GPIO by the Raspberry Pi. We all know the oscillator frequency of the Raspberry Pi is not an integer multiple of a sample rate frequency, see: The Raspberry Pi: Audio out through I2S | Dimdim's Blog, so this must be done to have any hope of a low jitter signal.
I did run a PCM5102A in PLL mode in comparison to the HiFi Barry DAC + Pro, and if you know what lower jitter sounds like - this is it. The sonic advantage is clear. I applaud HiFi Berry for being the first to do this in a Pi HAT. It is the reason I bought it. And, I’m still glad I did - in spite of the wifi frustrations which I feel now are basically moot.
Before we get into what I did to the HiFi Berry DAC + Pro let me say, I’m a TI/BB DAC chip fan, have been for a long time. I’ve tried many others, one of which is the ESS brand. I know there are HAT DACs using the ESS chip(s) with their own oscillators but I always hear the ASRC in those designs.
The secret to getting good sound from the PCM51XX series lies in the implementation and, more so, to the supplies. Here’s what I did.
1 - I used WBT Nextgen RCA jacks. This is a no brainer in my opinion and makes a noticeable difference. I caution anyone against removing the RCA jacks on the HiFi Berry DAC + Pro. The traces from the PCM5122 output filter to the through hole solder connections provided for adding your own RCA jacks is quite thin and goes under the on-board jacks. Frankly, I think HiFi Berry could have done a bit better job here with this trace work. You’ve been warned.
2 - I changed the caps (C7, C8) in the LPF after the PCM5122 to PPS caps, Digikey P/N PCF1457CT-ND as suggested by Greg Stewart. Generally, I have found over more than a decade of messing with DACs that more often than not, you’re better off without these LPFs. But, not in this case. Changing to this type of cap (PPS) is a definite improvement.
3 - I also did the other capacitor changes suggested by Greg; but, once you’ve done the supply changes below, their efficacy is reduced.
4 - For the PCM5122 analog supply, I removed the 0 ohm resistor (R14) and the on-board 5 to 3.3V regulator (U2), bridging across the input and output pin land areas, and feed 3.3V into P3. The regulator in the supply is the TI TPS7A4700, see: 4.17uV Ultralow noise DAC power supply regulator 3.3V/5V 1Ax2 - DIYINHK I’ve found over time that I prefer TI regulators with the analog section of Ti DAC chips - go figure… If you want to leave the on-board regulator and feed 5 volts in, you can do that; but, it is a little better without U2. Kind of a trade off between the regulator being proximate the load and having a better regulator.
For completeness, a garden variety LM317 based, a discrete current sourced, shunt regulated, and several other of the latest generation series type regulators were compared here. The TPS7A4700 won out.
5 - For the PCM5122 digital section and the clocks, having bent pins 1 and 17 over in the GPIO header, I put a white wire jumper between GPIO extension header through holes 1 and 17 and feed 3.3V into vias 17 (+3.3v) and 20 (GND). The supply is based on the LT3042 with a pass element for additional current handling and has a common-mode choke on the input, see: 0.8uV Ultralow noise DAC power supply regulator 3.3/5/7V 1.5A*x2 - DIYINHK The notion here was to provide the wildly varying peak peak current demands associated with processing while prevent any noise from making its way in or out of what was being supplied.
I did try separate supplies for the digital section of the PCM5122 and the clocks; but, frankly, there wasn’t enough difference to make it worth the trouble.
Again, for completeness, a number of supplies as mentioned herein above were compared; but, this one won out.
6 - For the AC feed to the two above supples, I use a 50VA 6V+6V toroid, having a 4.17 amp rating per winding. I tried lesser rated toroids and E/I based transfomers but the 50vA toroid really made the sound stage much, much better. I was surprised.
Conclusion
Finally, all of the forgoing was mounted to a 7” by 12”, 1/8” thick 6061 aluminum plate. Front and rear panels were fabricated from 1” by 1/2” aluminum channel stock. A lid of correspondingly sized 6061 (not shown) was also made. The difference from mounting everything to the plate may likewise come as a surprise to some; but, I’ve had this happen before. Metal standoffs and rigid often times helps clocks and, in this case, you could sure hear it.
At this point, there’s not a lot else to try. Maybe some galvanic isolation; but, that’s about it.
Hopefully, this inspires others to try something. You just might find that having a USB interface between you computer and your DAC isn’t all it is cracked up to be...
Hi @ultrafi
Really nice, you brought it all together! Congrats!
I see you measured the power draw on the pi3… did you see along the way I measured the piZERO and talked about it awhile ago?
...decoupling the wifi really stabilizes the piZERO power at constant ~100mA, with wifi attached, huge ~100mA to ~220mA swings constantly.
https://support.hifiberry.com/hc/en-us/community/posts/206543509/comments/207182485
Just FYI, could be more low hanging fruit for you to try, plus the pi3 is weird with the clocks/wifi right now.
Also re: Dimitris’s blog post on the raw pi i2s, To learn a bit, measured and got the same period numbers he did with my rigol scope, the 44.1x multiple clocks are flapping all over the place, you can see it, whereas the 48x class is stable.
Really nice, you brought it all together! Congrats!
I see you measured the power draw on the pi3… did you see along the way I measured the piZERO and talked about it awhile ago?
...decoupling the wifi really stabilizes the piZERO power at constant ~100mA, with wifi attached, huge ~100mA to ~220mA swings constantly.
https://support.hifiberry.com/hc/en-us/community/posts/206543509/comments/207182485
Just FYI, could be more low hanging fruit for you to try, plus the pi3 is weird with the clocks/wifi right now.
Also re: Dimitris’s blog post on the raw pi i2s, To learn a bit, measured and got the same period numbers he did with my rigol scope, the 44.1x multiple clocks are flapping all over the place, you can see it, whereas the 48x class is stable.
Last edited:
Great writeup Larry. I especially like your detailing of the different options you tried and the results... very educational. I must admit my tweaking time is limited, I sometimes will try and compare a few options, but most often I just use what I've found worked in the past.
I'll respond more at length when I have more time.
Again, THANKS!
Greg in Mississippi
I'll respond more at length when I have more time.
Again, THANKS!
Greg in Mississippi
Last edited:
First off, thank you x1000 for the very detailed, and thoughtful write-up.
I've got a handful of pi's, a 3 and a few 0's. Over the holidays I setup the 3 with the HiFiBerry DAC+ pro, and added a Ralink rt5370 USB wifi adapter with external antenna (150M USB WiFi Wireless LAN Adapter w/ Antenna Raspberry Pi ralink rt5370 MAUS | eBay ). I tried volumio, moode, daphile, and had issues related to the wifi on all of them.
After a few frustrating sessions, I set it all aside to work on other projects. I've been meaning to dive back in and figure it out, but it looks like you've gone through it and have it settled. This is awesome!
Just to clarify, you set your router to _only_ use channel 10, or you configured your Pi to only use channel 10? or both?
Do you know if the pi 0 and hifiberry zero dac have the same issues? I haven't tested mine yet.
I am planning on running a few cat6 drops into my bedroom(where the pi3 is), as well as other rooms in the house. I would sure love to be able to use wireless until then though.
Thank you again for posting this solution, I will have to slice off some time in the next few days to test it.
Thanks~
Gable
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.