I run a local music server called Logitech Media Server. It was formerly a company called slim devices that built WiFi enabled internet radios that could stream from a local server and also be controlled locally through a browser or app, it is the same as a Sonos or Bose streaming solution. I currently have 2 Logitech devices and have also built another out of a Raspberry Pi, USB sound card (Pi has terrible audio) and an old Roberts radio. The Pi runs TinyCore linux so everything runs in RAM to stop the SD card being corrupted if it is just turned off.
My thoughts were to hook up a USB soundcard to the omega and run an OpenWRT flavour of opensource squeezbox software. There is one from 2012 called squeezslave, it's only ~200kb and as long as it runs could be what I need.
I thought I'd create this post to see if anyone is interested in something similar.
So im able to install the .ipk file to the Onion
If you run opkg list it comes up as squeezeslave-oss so you can easily remove it.
However I cant get it to run as it doesnt recognize my USB audio card, so thats next on the list.
Looking at dmesg when I plug in the audio card I get
[ 1572.280000] usb 1-1: new full-speed USB device number 3 using ehci-platform [ 1572.470000] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/platform/ehci-platform/usb1/1-1/1-1:1.3/0003:0D8C:013C.0002/input/input1 [ 1572.480000] hid-generic 0003:0D8C:013C.0002: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-ehci-platform-1/input3
this to me looks like its recognised the MIC (ie input) but not the output part of the card?
@Sawyer-McBride Have you been able to set up the cross-compile environment? I think you might need to compile some of the sound related kernel libraries and drivers into the firmware in order for the operating system to recognize the audio device.
@Boken-Lin Excellent, cheers for the tip. I havn't messed about with the cross-compile env yet, time to spin one up :)
Just bricked it :red_circle: hehe, now gotta do a recovery.
Setup the cross-compile env and looked like I added the required kernal modules, compiled it, once I've loaded it, it fails to boot. LED comes on for a short time then off again.
Need to have a look at the serial console although windows doesnt recognise the USB device :neutral_face:
@Sawyer-McBride Do you have an ethernet expansion? You will need that to reflash the firmware.
@Boken-Lin I have, although I've only got a mini-dock at the moment so will have to patch it on a breadboard. Have you any pinouts and/or a link to the re-flash guide, I did see another guy had to go through the process
I'm very interested in doing quite the same thing.
Did you have any success with running squeezeslave on the omega?
I am very interested in this as I intend to use the Omega and the "C-Media Electronics Inc." dongle as a wi-fi intercom for use in a community theatre for communication among the crew.
I would be very interested in this. I have been working with the Raspberry Pi to create remote speakers for church, but this could make a cheaper solution if it works.
Thanks for your hard work.
I've been poking at USB audio as well. It seems to be supported under OpenWRT via the 'kmod-usb-audio' package. Unfortunately, that one hasn't been built for the Omega yet. Hopefully it will be part of the larger batch of packages coming over in the future! :)
Thanks, fader. I didn't realize it hadn't been built yet. It is listed in:
opkg list | grep audio | grep usb
opkg list | grep usb
leaves a lot of experimenting yet to be done! Sadly, "opkg install sox" on most of these (sox here used as example) gives:
- satisfy_dependencies_for: Cannot satisfy the following dependencies for sox:
- kernel (= 3.18.20-1-7bed08fa9c06eb8089e82c200340ec66) *
- opkg_install_cmd: Cannot install package sox.
On the other hand, usbreset does seem to work so there is a connection to the 3D dongle.
@Ross-Pratt The error you are getting on "Cannot satisfy dependency" indicates the package expects a different (newer) kernel version than the one installed.
Unless the package really needs a feature that is in the newer kernel, it is usually OK to still install the package.
This can be done using:
- opkg --force-depends install <package-name>
The worst that can happen is that the installed package really doesn't work with the older kernel, in which case you can remove it using:
- opkg remove <package-name>>
And other than not having the package you want, you are no worse off.
FYI: I have done this with a few packages that initially indicate problem with kernel version dependency and have had no problems.
It's certainly something you could try but it's basically a guarantee that a kernel module of version X will not load in a kernel of version Y (or even X.0.1 :)). You can get away with ignoring those dependencies for userspace packages on occasion if they just need a feature provided by a given kernelversion which also happens to be present in the version you have installed (though you're still asking for trouble, as the feature may behave in different ways). But a kernel module has to be mapped into kernel memory, executed in Ring 0, etc. so there are both a lot more things that can go wrong and a lot more checks for specific versions before code gets to be loaded.
I'm hoping we get all the kmod-* packages over soon, as that will dramatically increase the amount of hardware we can play with!
I would basically agree with the comments by @fader
If you use a package that was intended for a different kernel release (even if it was for the same hardware) you do run a risk that it won't work - particularly if the package is for a kernel module.
There is a greater likelihood that a user mode package will work.
However, in my opinion you are highly unlikely to cause any damage by using a package with mismatching kernel version - and some times it is the only way to progress while waiting on getting the right version.
But bottom line is that it is up to the call of each individual to decide whether it is worth it or not and to have a recovery plan if it doesn't work (usually just a removal of offending package, sometimes a factory reset) - but a lot of this is all part of the experimentation/development process.
Thank you Kit and Fader! Oddly it was actually looking for an older version! I am on 3.18.23.
--force-depends install works a treat. I'm now filling my 8 gig stick with software that will probably turn out useless but I can't tell otherwise what will work.
I sure wish gforth was available.
@Ross-Pratt I am planning on using the same audio card I believe, a small white one? about £2.50 on ebay? I think it would be a very do-able project that would work well as long as we can get it to recognise the card!
@fader I did see that the Omega kernel doesnt have the feature enabled for kmod-usb-audio and also another audio related feature. I did try to custom build the kernel but bricked my omega, havn't had time to try again since doing a firmware recovery. It is defo still on my to-do list. @Boken-Lin did say in another thread that they might do a few different releases with differing kernels. If they do, hopefully they'll do one with the USB audio stuff! Until then next time I have some free time I'll try and custom build a firmware again! It's just a pain for me as to do a firmware recovery I have to jam wires into the minidock as my proper dock hasnt turned up yet (Battery dock has been delayed).
i'm planning to cross-compile kmod-usb-audio, it's just taking forever for initial build to finish, i have no idea how many hours have already passed. Hopefully I'll be able to compile it in next few hours.
I've tried with ignore-depends and even some other kmods from other repos but nothing works