alexandali wrote:
I'm successfully running F19 R7 on both dual and quad - in both cases
using the audio out.
I noticed the output level is very quiet - found a post that says this
is unavoidable.
Have you tried it in the actual system where the WB will be used in?
I also use the analog
Pascal Hibon wrote:
Have you tried it in the actual system where the WB will be used in?
I also use the analog output of the WB in my behind the ceiling project
and I had to apply a bit of attenuation in the amp because the output
was high enough for that application.
Thanks Pascal - I've
alexandali wrote:
Thanks Pascal - I've tried it with 3 different amps - two 'class d'
digital amps - a Topping TP20 and a no-name one - both based on the
TA2020 chip, and also an 'Edifier C3' which is supposed to have an input
sensitivity of 80 +/-20 mV. I don't have a scope these days so
I installed the F19-R8 Quad image, then went to wandboard:8081 in order
to configure the Samba Workgroup (under System) and to set up a static
ip address for the Wandboard (under Ethernet Interface Configuration).
All worked perfectly: thanks Clive.
I first updated logitechmediaserver 7.80 to
OK OK - I got it.
piCorePlayer1.15c was super with USB-DACs but analog and I2S cards had
problems. piCorePlayer1.15d fixed the analog audio and I2S problems but
the USB-audio was inferior.
BUT
This has been fixed in *piCorePlayer1.15e - so please test it and report
back.
*I need feedback on:
I've installed R8 on my Quad and all is playing well to my Transporter,
Radio and DIYINHK XMOS USB-SPDIF connected to the Wandboard.
There was only one issue I had, which was streaming using DSDPlay to my
Raspberry Pi/Wolfson Audio running Squeezelite. The Pi is connected via
WiFi and had *-r
badboygolf16v wrote:
I don't know if the issue is the Raspberry Pi being underpowered, WiFi
dropping out, or DSDPlay related. Thought I would mention it.
DSDPlay is streaming the tracks fine to the Wandboard (wired LAN), Radio
(WiFi) and Transporter (wired LAN). Gotta be a Pi issue...?
sbp wrote:
OK OK - I got it.
piCorePlayer1.15c was super with USB-DACs but analog and I2S cards had
problems. piCorePlayer1.15d fixed the analog audio and I2S problems but
the USB-audio was inferior.
BUT
This has been fixed in *piCorePlayer1.15e - so please test it and report
back.
Thanks for the info.
Playback seems much better over ethernet. I did notice some stuttering
for a minute or so, but on the whole is glitch free as opposed to
constant break ups via WiFi.
One of the files I have is DSD64 .dff, this plays OK and CPU goes to
about 98%. The other files are .dsf and
badboygolf16v wrote:
I'm not sure how DSDPlay works. My Squeezelite is built with LINUX ALSA
EVENTFD RESAMPLE FFMPEG LINKALL options. Does the conversion from DSD to
PCM happen in LMS?
Yes, that squeezelite exe isn't built with native DSD support, so your
Wandboard LMS is using the default
psketch wrote:
Hi Steen
Haven't had much chance to test thoroughly, but 15e doesn't seem to work
with HDMI at all - it just gives what sounds like white noise. Oddly,
the white noise is at the format of the source - I saw 44.1, 96 and 192
KHz depending on the source, but all just gave
OK please test piCorePlayer1.15f
Steen
piCorePlayer a small player for the Raspberry Pi (25MB in RAM).
Homepage: https://sites.google.com/site/picoreplayer/home and
discussion:
ab.wagener wrote:
Yes, its impossible to affect the output level in CSOS. You have to ssh
into the wandboard, userid and password is fedora, then type the
command alsamixer. With key F6 you choose the sound interface, with
key Up and Down you change the output level. The default level is
sbp wrote:
OK please test piCorePlayer1.15f
Hopefully HDMI is fixed (sorry I can't test HDMI)
Steen
No, sorry, still the same. I just also dropped back to 15b to make sure
nothing else had gone awry, and 15b is lovely. 15f still gives the same
white noise/hissing as 15e I'm afraid.
SQUEEZELITE-1.6.2-6.GITFE9FAC7
soxr multi-threading on by default.
Changes...
Code:
* Wed May 07 2014 - 1.6.2-6.gitfe9fac7
- Ignore z option and default to num_threads=0 for soxr_runtime_spec.
soxr will decide how many threads to use. (number of CPU cores
DSDPLAY-0.1-8.20140419GIT8D87CAD
soxr multi-threading on by default.
Changes...
Code:
* Wed May 07 2014 - 0.1-8.20140416git8d87cad
- Apply dsdplay-soxr-multi-thread.patch.
Enable soxr multi-threading.
Update...
Code:
16 matches
Mail list logo
