Miero, sorry to hassle but having problems testing.
I have Archlinux:
Linux alarm 3.12.0-rc6-4-ARCH #1 SMP Tue Oct 22 23:04:38 CDT 2013 armv7l GNU/Linux
Followed instructions including alternative for non-matching kernel version. All seemed OK but last command to load driver gave me:
-bash: echo: write error: Invalid argument
Any thoughts? If its the different version giving problems I will download the one you have documented.
Cheers,
Chris
I have Archlinux:
Linux alarm 3.12.0-rc6-4-ARCH #1 SMP Tue Oct 22 23:04:38 CDT 2013 armv7l GNU/Linux
Followed instructions including alternative for non-matching kernel version. All seemed OK but last command to load driver gave me:
-bash: echo: write error: Invalid argument
Any thoughts? If its the different version giving problems I will download the one you have documented.
Cheers,
Chris
Here is a very early preview if the "Botic" cape. The Botic is a creek in Prague. The name is a tribute to the work Miero has done on the driver for the project. I liked the name - so it is sticking.
Some feature will be (not all populated on the layout yet)
1) Buffered PCM/DSD out (DSD will take some driver work) The buffer protects the BBB from accidental overloading of the outputs.
2) I2C out
3) Dual ultra low jitter clocks with outputs for DACs which need them.
4) Optional external power.
5) On board linear reg for the clock/mux/buffers.
6) ADC and/or Rotary encoder input to control volume externally.
7) I2C display could also be used.
This is exciting as well, maybe a IR input?
It seems that one GPIO configured as input is enough for IR receiving with TSOP receiver:
How to Control the GPIO on a Raspberry Pi with an IR Remote | Mark's space dot com
Excellent thanks, being able to control my BIII with a remote is the way to go, (thanks GLT)
Had a stab at installing drivers for Debian (3.8.13-bone40 which is what I had handy on an SD card), all looking good, aplay -l showing the correct playback devices.
Squeezelite shows following:
default:CARD=Botic - TPA Botic, - Default Audio Device
sysdefault:CARD=Botic - TPA Botic, - Default Audio Device
I will connect to a DAC tomorrow and listen (I hope)!
Squeezelite shows following:
default:CARD=Botic - TPA Botic, - Default Audio Device
sysdefault:CARD=Botic - TPA Botic, - Default Audio Device
I will connect to a DAC tomorrow and listen (I hope)!
Russ,
Considering the price of the BBB, how about a low cost version? or make the PCB board available with pads for $3 clocks (I see the pads for the $30 CCHD-957s) and taking the power from the BBB (I see the pads for the TPS7A47 which are not diy-friendly...)
Considering the fact that the I2S comes out of a gigantic SoC, ultra low jitter advantage of external clocks may be lost
Considering the price of the BBB, how about a low cost version? or make the PCB board available with pads for $3 clocks (I see the pads for the $30 CCHD-957s) and taking the power from the BBB (I see the pads for the TPS7A47 which are not diy-friendly...)
Considering the fact that the I2S comes out of a gigantic SoC, ultra low jitter advantage of external clocks may be lost
For the Acko SXX boards people were using these silabs 590CD-ADG. They get programmed by digikey to the frequency you specify when you buy them. Maybe a good balance between performance and price? I think they fit the pads that are being proposed?
For me, the cape idea as Russ has shown would be perfect. I don't want to compromise on clocks, would rather pay a few bucks more for a higher quality result.
For me there is no appeal in packaging a dac chip onboard. To get the best SQ from any dac means a lot of work and a bunch of power supplies and I already have that.
Just wonder whether there is much mileage in adopting a master clock approach and bypassing the Buffalo onboard clock. Running everything in sync,as it were.
For me there is no appeal in packaging a dac chip onboard. To get the best SQ from any dac means a lot of work and a bunch of power supplies and I already have that.
Just wonder whether there is much mileage in adopting a master clock approach and bypassing the Buffalo onboard clock. Running everything in sync,as it were.
Yay. With a little guidance from Miero I have the driver loaded on Debian also. I want to do a complete build though, with Squeezelite and wifi for client control, so more Linux fun to be had before I can contemplate plugging it into my dac.
Be interested in the outcome of your listening test Chris.
Mark
I've tested WiFi UWN200 adapter yesterday and it must be on extension USB cable, otherwise silent crackling noises can be heard from the speakers - independent on volume, thus induced probably on the DAC board.
Nevertheless BBB was fine playing from network without sound artifacts and downloading 2MB/s data at the same time.
Tested with Arch Linux ARM with 3.8.13-17-ARCH kernel.
Nevertheless BBB was fine playing from network without sound artifacts and downloading 2MB/s data at the same time.
Tested with Arch Linux ARM with 3.8.13-17-ARCH kernel.
Just tried starting squeezelite and this was the result:
This is without a DAC attached but I do not believe that will make any difference. I will check on the Squeezelite thread as to possible cause.
Squeezelite is running tho and shows under LMS but its behaving strangely (when you pause goes back to start of track and restarts playing the track). I will attach the DAC anyway but not hopeful.
I recall I got the same message when I was trying the I2S drivers that come in the Debian for this level of the kernel, didn't get any sound then (those are the native drivers that output 48k for 44.1k input).
Further test - the speaker test Miero suggests works OK making sound (now connected to DAC). So my problem is likely with Squeezelite.
Code:
root@arm:~# squeezelite -o hw:CARD=Botic
[19:40:11.979379] alsa_open:303 unable to get period size: Invalid argumentThis is without a DAC attached but I do not believe that will make any difference. I will check on the Squeezelite thread as to possible cause.
Squeezelite is running tho and shows under LMS but its behaving strangely (when you pause goes back to start of track and restarts playing the track). I will attach the DAC anyway but not hopeful.
I recall I got the same message when I was trying the I2S drivers that come in the Debian for this level of the kernel, didn't get any sound then (those are the native drivers that output 48k for 44.1k input).
Further test - the speaker test Miero suggests works OK making sound (now connected to DAC). So my problem is likely with Squeezelite.
Last edited:
I have not exposed all the features of the Cape.
Also DACs that actually want to use the master clock (WM8741 etc) will want to be using a good one.
I see, I see. A reclocker and clock divider...
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.