TonyMac32

If I have only the DSI plugged in and no HDMI, the Tinker OS X-server goes down after a few minutes. I want to verify it with the HDMI plugged in, but there are definitely some bugs in the arrangement. Scratch that, I see that the "download" link on the main page gave me the really old image. Let me retest with the new one. For what it's worth, it was strange artifacting when I had it plugged into the HDMI after following the tutorial on Armbian.

https://www.head-fi.org/threads/schiit-yggdrasil-impressions-thread.766347/page-397 Alright, other than the common audiophile bickering, it is obvious the device has had a problematic past with USB. The C2 itself also seems to share in the blame with: https://volumio.org/forum/odroid-usb-audio-dac-issues-t5618.html Alright, one last thing, 'sudo armbianmonitor -u', paste the link. I doubt there are any errors since it's working with PA and such, but you never know. And it will tell us the kernel. If it's 3.14, you may see an improvement with 4.14. I don't handle the Odroid C2 builds, however mainline support should mean a better situation. @gkkpch may have something to add, at this point I'm out of ideas.

Yes please. The issue is the DAC is USB 2.0, but if it is only running USB Audio 1.0, then it's running "full speed" (12 Mbps)

run lsusb -t for me please

hmmmm, what else is on the USB? Unfortunately the USB on Amlogic devices is... interesting. I think the S905 should be fully supported, it's the s905x/d/w/omgwtfbbq that isn't completely there yet on mainline. Looking at that DAC, it has this little guy on the receiving end: Input Receiver, USB: C-Media CM6631A Can you give me the output of "lsusb -t" to verify the identity? Has this worked properly with A) another SBC or B ) Windows? The controller can handle all sorts of different transfer modes, so I have to wonder if the linux driver is choosing the "wrong one" looks like, from the vendor page for the IC: Going from there I found another vendor FAQ: http://rotel.com/faq/why-cant-i-play-192khz-audio-pc-usb-connection and from yet another source, showing 96 khz as maximum for USB audio 1.0: http://www.farnell.com/datasheets/1738852.pdf#subsection.3.4.2 (If the link doesn't take you to the right page, it is section 3.4.2) The DAC is most likely only capable of 192khz using a Windows master, and I would most likely question it's ability to handle 96khz with 24-bit payload in full-speed USB audio 1.0 mode. Have you tested with any 48khz 24-bit material?

I'm a little disappointed, I would have expected 10 GbE. To code for the flat memory model Intel SoC: http://flatassembler.net/

I have a second round prototype of a power mezannine board at fab, after some testing I'll let folks know how it goes. Would be far superior (read, safe) to plumbing unfiltered power to the GPIO.

try sudo cpufreq-set -g performance

I had this on the tinker board, check/adjust your cpu governor, that may be the issue getting the (isochronous, I believe?) packets there on time, 24 bits is 50% more data per transaction.

That's true, however looking at the Pi3 B+ power consumption vs it's performance numbers, honestly the Tinker isn't doing that bad. It runs 1.8 GHz and is enough more powerful to make the RPi look a bit silly, despite it's power demands. The question becomes much more about what you want to do, if you're looking for raw performance, you're going to need to do some work on the cooling of either of these boards and, if you're smart, power them via the header pins (I think the Pi3 B+ can be powered via the PoE pins, since really I think they're just a normal power header. Calling it PoE is IMHO misleading since you need a hat to do it anyway, something that's possible without the special header). I have a nearly allergic reaction to pure gimmicks like "GbE over USB 2.0", or "look how cool the raspberry on the wifi shield is!" or "We learned to help cool the CPU using the giant mass of copper in the PCB, the way they teach college kids to in second rate schools" <--- seriously, I learned that in university, it is one of your more basic engineering lessons where you use the least number of pieces to get the job done. A little more time routing, yes, but seriously, why build something halfway? An interesting comparison would compare power consumption during these benchmarks, the rk3288 boards will win the brute force numbers battle (for now the RK3399 will have it's day soon), and this didn't test the XU4. It's probable the s905(x) boards would win the power/performance battle, the NanoPi K2 and Libre Computer board I have both run extremely cool compared to the XU4/RK3288/H3 (H3 may just be vendor issues, I understand some run cooler than others) Cost/Performance becomes the next discussion, assuming heat and dissipation are not the worry, then you get the Pi3b+ in a price bracket (+/- $5) with the Libre Computer S905X (Le Potato)($35-40), The Libre Computer RK3328 "Renegade" with DDR4 and USB3 ($40), and a small pile of H3 boards which all have dedicated ethernet and more than one usb port. The Rock64 with 1 GB RAM is $25, so that $10 can go to getting a cheap Wifi dongle and you still wind up with true GbE, a USB3 port, etc. I like the board, I've made a firm statement about my opinion of the powering and cooling situation, but when all is said and done, we get fewer powering issues with it than I think anyone would have expected, most likely due to the PMIC. Were a community feedback version made (would be a solid move by any vendor for any board), a 2+2 2.54 mm powering header would be one of the first additions (if you simply must keep the RPI form factor), the next a bigger heat sink and a dedicated fan header for PWM cooling (basically all fan-integrating cases just plug them into the 5V GPIO pins). Even if you hate fans, there are times they need to happen, and it's best to have control of them so they can be silenced when appropriate.

This is a running problem with a lot of vendors. If the Tinker Board kernel was less specific to the Tinker, I'd use it directly and we'd have a lot less work to do "keeping up". But the handling of some of the hardware issues causes their kernel to crash other boards. At the moment I need to see about submitting some of the patches I use now to Rockchip, most do not affect other machines and can be merged easily. Hmmm, I tried the newest image with only the DSI screen attached, it locked up and started flashing the display after starting the web browser... <---- the download link on the product page still gives you 1.8, I didn't pay close enough attention, beware of that if you dl Tinker OS!

I fixed nanopi K2 image creation, when the board got renamed it broke the build, had to rename u-boot blob and bootscript. Meson64 default is now 4.14.y, next will become 4.16.y soon as the kernel enters stable.

Good catch. It could be because only Uart1 has cts/rts from what I can tell, and that might be needed somewhere besides a terminal... Hey, that was me!

It's an open-cell metal foam, so it has increased surface area. That said, I'm looking at how well it works, not necessarily whether it's perfect for this application. For something like the s905x, I'm betting this is good enough for a "normal" operation. For an RK3288 or RK3399, not a chance. Sent from my Pixel using Tapatalk

This may help, at least for where to go and look. I've only done this for the I2S as described for the NanoPi Neo. I just saw this thread, I may have some questions to ask soon, I'd like to start giving compact RT / IOT builds a shot for several devices.

Now, also a terrible idea for thermal, but possibly fun for the kids (and so able to be downclocked): https://www.amazon.com/gp/product/B01E10IXRQ The brick studs work quite well, and the board fit is perfect. As it turns out the other colors are all cheaper than black, which I think is... odd. This will go nicely with the lego-studded motors I got a while back.

The bus is an Open-Drain network. This protects as shorts, as the only actual impact a device can actively have is to ground it. 2 devices grounding isn't dangerous. The issue is resistance of the transistor itself, remember this becomes a voltage divider with the pullup and the transistor. The stronger and stronger the pullup, the more significant that RDSon becomes. Eventually the transistor is incapable of driving the signal low enough fast enough. The positive slew rate will be improved for the reason you mentioned, but falling edges will suffer.

For some reason the default UART utilized by uboot is uart2 on the Tinker. I haven't messed with it, and left it alone, but vendor uses UART1, and UART2 has a conflict with PWM pins. I'm in favor of changing, if anyone objects or has a more interesting idea, please discuss.

Opening a request for feedback on this one, I would change it immediately, but others may have designed around the current reality.

I was so confused. Kids, take heed in the power of reading.

I bought a couple for testing, could be useful

For u-boot you need to handle the ddr4 iirc. Other than that... Sent from my Pixel using Tapatalk

I haven't checked, but this is almost universally true of eMMC, there are several reasons, including the data bus typically being twice as wide, and eMMC is set up for application use, so usualy faster random I/O.

Current status, I'm posting from a 4.16-RC6 build. armbianmonitor -u output: http://ix.io/13hk Current patchset is working fine, I'll dig deeper later.