I believe that this discussion is PC hardware oriented.
I don't think that any PC/audio card is really a winner in sound terms.
Jitter, noisy PC power supplies, opamps .... do not contribute to good sound.
The way to go is embedded Linux audio. And there are quite some commercial embedded Linux devices out there that sound good (high end!) - more that you would imagine.
But these guys pay their engineers to write drivers and userland software.
Moral: if you expect that the open source based project will solve all your problems in 1-2 days, you're wrong. It does take time and yes, it costs money to build such gear.
Unless you are ready to contribute by submitting changes or discussing ideas be ready to get what you paid for and be patient - wait for the community to solve your problem. Beware - your problem might not be the most important one ....
By using Linux you are essentially given an extremely powerful set of tools and building blocks to build upon. How far you get will depend on your will or ability to tailor the stuff to your needs.
Or buy Microsoft or Apple. You get what you paid for, either with money (proprietary), or effort (free software). In essence, taking everything cost free and expecting it to be perfect and well supported - the community strives to this goal but do you really think it is fair to expect that? Remeber, you pay money for software with bugs and design flaws that will never ever get fixed.
I don't think that any PC/audio card is really a winner in sound terms.
Jitter, noisy PC power supplies, opamps .... do not contribute to good sound.
The way to go is embedded Linux audio. And there are quite some commercial embedded Linux devices out there that sound good (high end!) - more that you would imagine.
But these guys pay their engineers to write drivers and userland software.
Moral: if you expect that the open source based project will solve all your problems in 1-2 days, you're wrong. It does take time and yes, it costs money to build such gear.
Unless you are ready to contribute by submitting changes or discussing ideas be ready to get what you paid for and be patient - wait for the community to solve your problem. Beware - your problem might not be the most important one ....
By using Linux you are essentially given an extremely powerful set of tools and building blocks to build upon. How far you get will depend on your will or ability to tailor the stuff to your needs.
Or buy Microsoft or Apple. You get what you paid for, either with money (proprietary), or effort (free software). In essence, taking everything cost free and expecting it to be perfect and well supported - the community strives to this goal but do you really think it is fair to expect that? Remeber, you pay money for software with bugs and design flaws that will never ever get fixed.
They told us to transfer the stuff by ourselves.
Anyhow -- I am in the phase to set my own wiki.
I had a glance at Voyage Linux, since some people around here seem to be happy with it.
Questions to the folks using Voyage:
1. From what I can see they are running pretty old stuff. Are you all running
that old stuff (kernel,libs, etc.)?
2. Did anybody manage to load the entire system to RAM at boot? It seems that they provide scripts to be able to load at least parts of the system to a tmpfs drive.
THX
Questions to the folks using Voyage:
1. From what I can see they are running pretty old stuff. Are you all running
that old stuff (kernel,libs, etc.)?
2. Did anybody manage to load the entire system to RAM at boot? It seems that they provide scripts to be able to load at least parts of the system to a tmpfs drive.
THX
Well, I went back from gentoo. It was a few years ago and I just could not make the graphics card display correctly (I guess the open source radeon driver at that time). The problem was with the font rendering infrastructure - the fonts would be blurred in vertical stripes. Very faint but my eyes are very sensitive to that (e.g. I cannot use subpixel aliasing since it adds a hint of disturbing rainbow to fonts - most of my colleagues do not even see that, I have to use only simple gray aliasing). Ubuntu/debian were OK at that time.
Plus I just did not like the setup of config options - many applications defined their own names (some provided identical functionally but had a different name). I had a feeling there was no centrally administered and binding set of options.
I ended up with defining a set of options for every major package and that was a nightmare to administer. The machine was compiling all the time while I actually did no productive work.
But perhaps I did not use gentoo correctly and it may have improved since then.
Nice try. It's not that easy I'd guess. Sorry for not being clear about my requirements.
Below my requirements - see also my ratings:
1. Very flat base system - starting from scratch ( Voyage-50%OK, Tiny Core-OK)
2. Up2date - newest kernel, libs and packages (Voyage-NOK, Tiny Core-OK)
3. Package-Management - availability of packs at all (Voyage-50%OK because of old base, Tiny Core-NOK)
4. Adaptable - how easy it is to bring in own packages (Voyage-50%OK because of old base, Tiny Core-NOK)
5. Fully loadable to RAM ( Voyage-50%OK, Tiny Core-OK)
6. OS complexity and management tools, thus difficult to maintain ( Voyage-OK, Tiny Core-NOK)
7. Community Support ( Voyage-NOK- however Debian/Ubuntu can be used as backup, Tiny Core-OK)
Bottom Line: For my purposes Voyage might be the perfect choice, if newer packages were available and full load to ram would be possible. Exactly at these points TC beats Voyage. Though I have to admit that I neither tried to upgrade the Voyage packages manually, nor I tried to pull them from other repos.
Ratings OK-NOK must be seen in the context of "how much effort to be put in".
Last edited:
Which brings me back to Slackware, Gentoo - been there done that got the tee-shirt .... etc. it has its merits, and it's problems ... , Ubuntu/Debian is simple easy, convenient, but always ends up with more than I want or need installed, other peoples ideas of what are required dependencies ...
Never had much joy with RPM based distro's, tho SuSE is not Bad ... , as above that brings me back to Slackware .... , must really build a tagfile set for the following packages, ... , with these, I can go anywhere, compile anything ... , and if audio only is the target, then I can strip out some of these as well ... , am getting tired of fighting package manages ... , not that they are inherently bad, but ... , they don't always do what I require them to do ... , these for a 64-bit setup - 32-bit is similar ...
aaa_base-20090717-x86_64.txz
acpid-1.0.8-20090716-x86_64.txz
alsa_lib-1.0.20-20090716-x86_64.txz
alsa_oss-1.0.17-20090716-x86_64.txz
alsa_utils-1.0.20-20090716-x86_64.txz
attr-2.4.43-20090717-x86_64.txz
bash-4.0.24-20090716-x86_64.txz
bzip2-1.0.5-20090716-x86_64.txz
calc-2.12.4.0-20090716-x86_64.txz
coreutils-7.4-20090716-x86_64.txz
dhcpcd-4.0.13-20090716-x86_64.txz
dialog-1.1-20090716-x86_64.txz
diffutils-2.8.7-20090716-x86_64.txz
dmidecode-2.10-20090716-x86_64.txz
e2fsprogs-1.41.6-20090716-x86_64.txz
ethtool-6-20090716-x86_64.txz
expat-2.0.1-20090716-x86_64.txz
fbida-2.07-20090716-x86_64.txz
fetchmail-6.3.8-20090716-x86_64.txz
fftw-3.2.1-20090716-x86_64.txz
file-5.00-20090716-x86_64.txz
findutils-4.4.2-20090716-x86_64.txz
fontconfig-2.6.0-20090716-x86_64.txz
freetype-2.3.5-20090716-x86_64.txz
g++libs-4.3.3-20090716-x86_64.txz
gawk-3.1.6-20090716-x86_64.txz
glibc-2.10.1-20090716-x86_64.txz
gmp-4.3.1-20090716-x86_64.txz
gpm-1.20.6-20090716-x86_64.txz
grep-2.5.4-20090716-x86_64.txz
gzip-1.3.12-20090716-x86_64.txz
inetutils-1.6-20090716-x86_64.txz
ivtv_utils-1.4.0-20090716-x86_64.txz
kernel_modules-2.6.30.1-20090717-x86_64.txz
lame-3.98.2-20090716-x86_64.txz
less-429-20090716-x86_64.txz
lftp-3.7.11-20090716-x86_64.txz
libcap-2.16-20090717-x86_64.txz
libexif-0.6.16-20090716-x86_64.txz
libjpeg-v6b-20090716-x86_64.txz
libpng-1.2.31-20090716-x86_64.txz
lilo-22.8-20090716-x86_64.txz
links-2.2-20090716-x86_64.txz
mc-4.6.2pre1-20090716-x86_64.txz
module-init-tools-3.6-20090716-x86_64.txz
mplayer-SVN.r28467-20090716-x86_64.txz
mutt-1.5.18-20090716-x86_64.txz
nbsmtp-1.00-20090716-x86_64.txz
ncurses-5.7-20090716-x86_64.txz
net_tools-1.60-20090716-x86_64.txz
openssh-5.2p1-20090716-x86_64.txz
openssl-1.0.0.beta2-20090716-x86_64.txz
patch-2.5.9-20090716-x86_64.txz
pciutils-3.1.3-20090716-x86_64.txz
pkgtools-12.34567890-20090716-x86_64.txz
procmail-3.22-20090716-x86_64.txz
procps-3.2.8-20090716-x86_64.txz
psmisc-22.3-20090716-x86_64.txz
readline-6.0-20090716-x86_64.txz
sed-4.2-20090716-x86_64.txz
shadow-2.1.4.1-20090716-x86_64.txz
speex-1.0.5-20090717-x86_64.txz
sysklogd-1.5-20090717-x86_64.txz
sysvinit-2.86-20090717-x86_64.txz
tar-1.22-20090717-x86_64.txz
tiff-3.8.2-20090717-x86_64.txz
udev-141-20090717-x86_64.txz
util_linux_ng-2.14.2-20090717-x86_64.txz
wget-1.10.2-20090717-x86_64.txz
which-2.16-20090717-x86_64.txz
wireless_tools-30.pre8-20090717-x86_64.txz
xvidcore-1.1.3-20090717-x86_64.txz
xz-4.999.8beta-20090717-x86_64.txz
zlib-1.2.3-20090717-x86_64.txz
There is always a hazard using the bleeding edge latest- it may well have some latent bugs that can bite.
However Voyage 6 uses 2.6.26. He is working on Voyage 7, using 2.6.30. You can install the upgraded kernel pretty easily. I also switched to sid and have had no problems yet with broken or bad packages. I have had to build my own kernel, but that was not too painful. Not for the rank amateur however. There are many very frustrating bumps in the road until you get it down. Its really months of experimentation to get it working, figure out the details etc. for any of these systems. My goal was an appliance, running completely from flash with a read only file system (looks like the spec for a Linksys router). No local UI and nothing running on the box that doesn't specifically support the requirement of playing high rez files. Voyage can do it. So can Mint but it and Ubuntu bring a lot of overhead. I have not tried Tiny Core (don't relish going down another bumpy road) but it may be perfectly fine.
However Voyage 6 uses 2.6.26. He is working on Voyage 7, using 2.6.30. You can install the upgraded kernel pretty easily. I also switched to sid and have had no problems yet with broken or bad packages. I have had to build my own kernel, but that was not too painful. Not for the rank amateur however. There are many very frustrating bumps in the road until you get it down. Its really months of experimentation to get it working, figure out the details etc. for any of these systems. My goal was an appliance, running completely from flash with a read only file system (looks like the spec for a Linksys router). No local UI and nothing running on the box that doesn't specifically support the requirement of playing high rez files. Voyage can do it. So can Mint but it and Ubuntu bring a lot of overhead. I have not tried Tiny Core (don't relish going down another bumpy road) but it may be perfectly fine.
Demian,
did you try OpenWRT for your embedded projects? I have built an internet webcam based on Asus WL500gP for monitoring my friend's new house construction site (live MJPEG stream, storing pictures on 32GB USB stick, web interface with streaming past hours/days in MJPEG, connection to internet via 3G USB modem, VPN to a backbone server for static IP (I could have used DynDNS instead), wifi AP for wireless access to the webcam and to internet from the construction site, etc.). I found it very developer-friendly. I had to modify some C code of mjpeg-streamer - developed and tested in ubuntu, then on the same machine compiled/built an opkg package for MIPS using a single command of the OpenWRT SDK. The new package installed and worked flawlessly.
Stock OpenWRT offers usb-audio modules, alsa-utils, MPD and other audio-related packages.
Of course this kind of project is not for beginners but I cannot imagine how a beginner could hack an embedded distribution (CLI only, the feature-limited shell of busybox, etc.)
did you try OpenWRT for your embedded projects? I have built an internet webcam based on Asus WL500gP for monitoring my friend's new house construction site (live MJPEG stream, storing pictures on 32GB USB stick, web interface with streaming past hours/days in MJPEG, connection to internet via 3G USB modem, VPN to a backbone server for static IP (I could have used DynDNS instead), wifi AP for wireless access to the webcam and to internet from the construction site, etc.). I found it very developer-friendly. I had to modify some C code of mjpeg-streamer - developed and tested in ubuntu, then on the same machine compiled/built an opkg package for MIPS using a single command of the OpenWRT SDK. The new package installed and worked flawlessly.
Stock OpenWRT offers usb-audio modules, alsa-utils, MPD and other audio-related packages.
Of course this kind of project is not for beginners but I cannot imagine how a beginner could hack an embedded distribution (CLI only, the feature-limited shell of busybox, etc.)
ICE1724 does no volume control, it is provided by AK4358. Check page 20 of http://www.asahi-kasei.co.jp/akm/en/product/ak4358/ak4358_f01e.pdf , 0dB corresponds to value 7Fh of the ATTE register. Page 27 shows that right channel first DAC - reg. 04h, left channel - reg. 05h, the remaining volume registers are for analog in monitor (06h+07h), digital out monitor (08h+09h), digital in monitor (0Bh+0Ch).
Current hexadecimal values of all AK4358 registers are listed in /proc/asound/Juli../ak4358 (simple checking by e.g. watch -n 0.5 cat /proc/Juli.../ak4358). The card itself offers only PCM volume, Master volume is a virtual control defined by the driver "pulling" all the four HW volume controls provided by AK4358. Therefore both master and PCM must be at 100% to reach value of 7Fh for registers 04h and 05h.
Last edited:
THX a lot. Very valuable information.
One more - just for clarification:
The guys I am working with tapping off I2S off the Juli to feed a Buffalo DAC. This is done before the DAC chip I'd guess. From that perspective the 4358 mixer should be out of the game.
I am running hw:0,0 . However alsamixer master control still works!?!? How ?-- if the DAC is out of the loop.
Let me know what's wrong with my understanding of the whole stuff.
BTW: I made the system work the other day by reinstalling it. Something must have been badly messed up.
Last edited:
By works do you mean "is present" or "changes really the volume"?
The driver has no information that the DAC is bypassed and defines the volume controls as usual. It should not have any effect on I2S though.
Weird things do happen and will always do
Do you have any notes on what you needed to do, and how small/large is the end installation?
Have a IDE CFDISK adapter and a few 64M CFDISKS and a single 2Gig. CFDISK ...
Soundcheck,
I realized one more case. Pulseaudio redefines default alsa controls with its own minimal set and alsamixer displays controls of pulseaudio. If you want controls defined by the card itself, you have to use
alsamixer -c0
I would assume volume controls of pulseaudio regulate the actual stream by default.
I realized one more case. Pulseaudio redefines default alsa controls with its own minimal set and alsamixer displays controls of pulseaudio. If you want controls defined by the card itself, you have to use
alsamixer -c0
I would assume volume controls of pulseaudio regulate the actual stream by default.
I somehow got started with Voyage and it seemed to work. OpenWRT also is promising but didn't seem to be necessary for an X86 platform. With Linux there is always another option. Using the command line brought me back to the old days of cpm. But there were a lot of dead ends trying to figure out how to get the final box together. If there is any success I will hand off the software development to a real Linux geek.
I had to build all of the sound stuff from source to get it to work. It all fits in around 2 GB of flash.
That's an interesting one. I never realized that the alsamixer without -c refers to the "default" device . Because usually "default" is card 0.
Someone really need to write all that down.
THX.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.