1. Use tab key for file completion
2. Use ls command to check what is in your current directory. Clearly the file name you are using is not there. In your listings (not the screenshot) you wrote Rasby instead of Raspy... - see the point 1.
dding an image file to your device is truly trivial, a matter of seconds.
2. Use ls command to check what is in your current directory. Clearly the file name you are using is not there. In your listings (not the screenshot) you wrote Rasby instead of Raspy... - see the point 1.
dding an image file to your device is truly trivial, a matter of seconds.
Are you absolutely sure the file is in your current directory?
Check where you are with:
pwd
then check that the file is actually there, and the exact name:
ls
Then you can test dd with the full path from first command.
At least that's what I would do - it's all very basic *nix stuff and have nothing to do with RasyFi, you should be able to solve it.
Good luck!
Check where you are with:
pwd
then check that the file is actually there, and the exact name:
ls
Then you can test dd with the full path from first command.
At least that's what I would do - it's all very basic *nix stuff and have nothing to do with RasyFi, you should be able to solve it.
Good luck!
Must be your typo as the dd command ran first time round for you when you were executing as non-root user.
If you are not familiar with Linux then you may want to steer away from the OS as, in my experience, things won't go as smoothly as they (mostly) do on PC's and Mac's. And when they don't, you will need to use CLI tools like vi, cat, more, etc. in order to debug. Also, when you are operating as root, is possible to make unrecoverable mistakes.
What were the updates? Were these applied via apt-get update && apt-get upgrade? It would be better to note what changes you made and then notify the RaspyFi project of problems than simply to abandon its use.
RaspyFi is neither closed nor monlithic in design. At heart it is similiar to raspbian with some packages removed and others added: critically, MPD and the WEBUI stuff, plus of course their tweaks for better audio SQ.
If it doesn't survive a normal package update then RaspyFi needs to know. If you added packages of your own choice which cause a problem RaspyFi need to know.
Eudyptes,
Do you know if the tweaks for better SQ are described in detail anywhere? I had a quick look at the RaspyFi site but couldn't easily find it.
Are the main alterations around processes and tuning, or have changes been made to the code for audio binaries?
I have (tentatively) tuned MPD myself, and don't need a UI, which is why this is important to me. I am prepared swap out Raspbian for RaspyFi if I can know and understand the core modifications.
I know MA is best situated to answer this, but he hasn't so far and my question is probably getting lost in the depths of this thread.
TIA
Do you know if the tweaks for better SQ are described in detail anywhere? I had a quick look at the RaspyFi site but couldn't easily find it.
Are the main alterations around processes and tuning, or have changes been made to the code for audio binaries?
I have (tentatively) tuned MPD myself, and don't need a UI, which is why this is important to me. I am prepared swap out Raspbian for RaspyFi if I can know and understand the core modifications.
I know MA is best situated to answer this, but he hasn't so far and my question is probably getting lost in the depths of this thread.
TIA
Looks good, see my post http://www.diyaudio.com/forums/pc-b...to-audiophile-audio-player-6.html#post3650010
Next time use the tab key for file/command completion to avoid the incorrect filename. Just start typing the filename, hit tab and shell will complete or offer candidates. These issues were already solved 40 years ago when unix was created
Its awesome
Yea, well done! :thumbup:
---
Sent a long time ago from a Galaxy [Tab] far far away using Tapatalk HD
Here is the info on the tweaks: http://www.raspyfi.com/raspyfi-rc2-how-its-made-and-list-of-all-the-optimizations/
It's for RC2 but it's a good start anyway.
---
Sent a long time ago from a Galaxy [Tab] far far away using Tapatalk HD
Thanks Heffa.
I seem to have done much of this already, but there are a few things in there which I will attend to. Nice to see such a comprehensive list in one place. And apologies for not spotting it, it was right under my nose.
There are also some other things I have done which aren't mentioned there, but could certainly affect performance. MPD, for instance, has some very tight loops which can work the CPU hard under the wrong conditions. I discovered this when my SD card ran out of space recently due to log files being written to by MPD several hundred times a second.
I found a cure for this without needing to alter the MPD source code, nevertheless I may revisit it as I really don't like the idea of tight 'while' loops being invoked under certain conditions. I would rather that MPD simply exit gracefully.
I should point out that I never get drop-outs, cracks, pops, or the like with MPD - it has been very stable for me. However, it - or the RPi - seems very sensitive to hardware, as one USB-SPDIF converter I demo'ed recently really struggled to hold its signal.
An interesting topic would be whether anyone hears improved performance through manipulation of the two MPD buffer settings.
I seem to have done much of this already, but there are a few things in there which I will attend to. Nice to see such a comprehensive list in one place. And apologies for not spotting it, it was right under my nose.
There are also some other things I have done which aren't mentioned there, but could certainly affect performance. MPD, for instance, has some very tight loops which can work the CPU hard under the wrong conditions. I discovered this when my SD card ran out of space recently due to log files being written to by MPD several hundred times a second.
I found a cure for this without needing to alter the MPD source code, nevertheless I may revisit it as I really don't like the idea of tight 'while' loops being invoked under certain conditions. I would rather that MPD simply exit gracefully.
I should point out that I never get drop-outs, cracks, pops, or the like with MPD - it has been very stable for me. However, it - or the RPi - seems very sensitive to hardware, as one USB-SPDIF converter I demo'ed recently really struggled to hold its signal.
An interesting topic would be whether anyone hears improved performance through manipulation of the two MPD buffer settings.
Would you care to elaborate on this a little more?
I for sure am interested, and I'm sure the RaspyFi project is too
It has been argued that the RPi's USB hardware implementation is not ideal. Things normally done in hardware are left to a driver that has only gradually improved. Hence much complaining about various USB problems on forums. And I've read that ARM based devices have a generic problem which requires the use of a USB hub for non-UAC2 asynch USB DAC's to work.
Anyyway, it may be of interest to some that Tsunamp/RaspyFi have posted their code on Github - https://github.com/Tsunamp/RaspyFi
Yes. Standard procedure.
I just installed vim.
This is a known issue.
I found out after i broke my installation.
Forum - RaspyFi
By monolithic i mean WEBUI and tweaks are interlocked, so you cant have one without the other. I would prefer a more modular approach.
I just found command/orion_optimize.sh in the Tsunamp repo to contain some of the tweaks i was looking for.
Hopefully this helps me to fix my network issues.
The problem with the USB Controller on RPi is, that it shares the Bus with Ethernet Controller. Other ARM Board have another (better) Design.
So far the HDMI Controller seems to me to be better suited for high quality audio on the RPi. Although there are other issues.
Raspberry Pi • View topic - DTS-MA passthrough
Would you care to elaborate on this a little more?
I for sure am interested, and I'm sure the RaspyFi project is too
Sure.
I can't remember the full details off the top of my head, but MPD was filling the kern.log (and other log files I think) with huge amounts of trace relating to some kind of delay parameter.
Adding
options snd-usb-audio nrpacks=1
to alsa-base.conf cured it.
I noticed just now that the RaspyFi site also recommends to add this line, although no explanation is provided.
Going slightly OT here, but can anyone point me toward an online resource which explains how USB data exchanges take place between a source and a target (e.g. DAC, or offboard converter)?
I would like to get my head around the transfer of data (and clock?) in order to better focus my attentions on improvements. I have a reasonable understanding of SPDIF and I2S but can't seem to find anything digestible for USB with audio.
What Audio formats do you want to play?
Only compressed formats, like dts and ac3?
Or also TrueHD and DTS-Master?
DSD?
Why do you want to use the USB Bus?
A AVR is pretty much the 5.1 (7.2) DAC you are looking for, only with HDMI Input (and some extras).
Whether a High-End AVR is audiophile or not is open to discussion, i guess.
Also whether HDMI meets audiophile standards can be discussed
But the lossy multichannel formats USB can handle are definitely not.
Although i greatly enjoy them on my system.
Dark Side of the Moon in dts sound like its made for that format.
But then i am not to worried about audiophile.
YMMW
Only compressed formats, like dts and ac3?
Or also TrueHD and DTS-Master?
DSD?
Why do you want to use the USB Bus?
A AVR is pretty much the 5.1 (7.2) DAC you are looking for, only with HDMI Input (and some extras).
Whether a High-End AVR is audiophile or not is open to discussion, i guess.
Also whether HDMI meets audiophile standards can be discussed
But the lossy multichannel formats USB can handle are definitely not.
Although i greatly enjoy them on my system.
Dark Side of the Moon in dts sound like its made for that format.
But then i am not to worried about audiophile.
YMMW
Last edited:
A few posts I wrote on this subject. All this relates to x86 usb, ARM may differ a bit, but the principles hold.
How to set up MPD on Ubuntu 11.04 - Page 10 and consequent posts (quite a few)
More of a test, but shows the principles a bit too http://www.diyaudio.com/forums/pc-based/93315-linux-audio-way-go-92.html#post1719044
Of course your ARM USB controller will have a different implementation - but the ultimate documentation - linux source code for your USB controller is readily available
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.