What I mean is a software / hardware solution. I've been doing a bit of reading about what the Windows monkeys are doing and it seems to typically involve at least two of these three adjectives: complicated, expensive, unstable, technically inadequate (e.g. using multiple DACs with no regard to clock syncronization).
in linux relatively too
ok, free in linux
if you script your well-tested equalising chain to start reliably, than I would say stable
That is a hardware issue, common to all OSes. In linux it is easier to merge soundcards though.
IMO multichannel output is no major problem in linux, there are numerous multichannel soundcards, USB adaptive DACs can be safely merged using the multi alsa plugin (the major linux advantage), etc.
Hi folks.
I'm playing around with a tiny Android 4.1.1 device.
I just hooked up my good old EMU 0404 USB to it.
It was immediately recognized.
The problem is now that I'd need amixer (alsa-utils) to set the samplerate.
It seems that nobody is considering alsa-utils a useful package for Android.
Question: Is it possible to set the driver parameters that are usually set via amixer also diretcly via /proc/asound ??
Thx
Cheers
I'm playing around with a tiny Android 4.1.1 device.
I just hooked up my good old EMU 0404 USB to it.
It was immediately recognized.
The problem is now that I'd need amixer (alsa-utils) to set the samplerate.
It seems that nobody is considering alsa-utils a useful package for Android.
Question: Is it possible to set the driver parameters that are usually set via amixer also diretcly via /proc/asound ??
Thx
Cheers
using multiple devices as a composite audio device (called aggregate audio device) has been possible in mac OS for many years, or you speak of an advantage vs windows?
This thread: [android-porting] ALSA on x86 - No sound may hold some clues for you. They mention alsa_mixer and saving the settings in /system/etc/alsa_config.
This thread: [android-porting] ALSA on x86 - No sound may hold some clues for you. They mention alsa_mixer and saving the settings in /system/etc/alsa_config.
Nice job.
With optimum settings you can get rid of almost every artifact with sox.
I'm wondering how you'd use or choose the sox resampling parameters properly. There are endless options. I tried several different ( I wrote once an article on my blog)
I wouldn't be happy with just low,mid,high quality options or similar.
BTW:
As far as a I recall integer float conversions are ususally lossless resp. bitperfect if you look at a 24bit output only. If you step up to 32bit that might change.
Beside that you can read over at AA and elsewhere that quite some people hype about integer mode (certain player software seem to supply such a playback mode) sounding better then float mode. Basically they try to avoid int-float-int conversions.
Keep up the good work.
Cheers
With optimum settings you can get rid of almost every artifact with sox.
I'm wondering how you'd use or choose the sox resampling parameters properly. There are endless options. I tried several different ( I wrote once an article on my blog)
I wouldn't be happy with just low,mid,high quality options or similar.
BTW:
As far as a I recall integer float conversions are ususally lossless resp. bitperfect if you look at a 24bit output only. If you step up to 32bit that might change.
Beside that you can read over at AA and elsewhere that quite some people hype about integer mode (certain player software seem to supply such a playback mode) sounding better then float mode. Basically they try to avoid int-float-int conversions.
Keep up the good work.
Cheers
Member
Joined 2009
This successfully installed amixer on my phone. The author is very responsive to requests.
https://play.google.com/store/apps/details?id=com.skvalex.alsamixer&hl=en
I'll give it a try. I hope I can make it autostart to run the device headless.
Thx a lot.
My current test was just using the libsamplerate API by libsoxr-lsr, i.e. the "emulation" of best, medium, etc. libsamplerate configs. I want to use straight libsoxr. Params would be either the pre-prepared combinations
soxr.h - audacity - Audacity: Free, Cross-Platform Audio Editor and Recorder - Google Project Hosting , or all the parameters soxr.h - audacity - Audacity: Free, Cross-Platform Audio Editor and Recorder - Google Project Hosting . That would require adding an option to the alsa-lib config code.
Where can you get a 32bit source material? Plus taking into account the real-world resolution od DACs is only about 20 bits.
First, I do not care about hypes and nobody of those fretting about the so called "integer mode" ever presented any credible listening test result.
Second, the resampling itself takes quite some CPU, several orders more than two format conversions.
Third the resampling libraries internally use float (or float64 for the double precision mode in libsoxr), the conversion has to occur somewhere.
Have you played with different options for "best" to get the artifacts in your graphs out?
e.g.
rate -v -p 25 -b 93 192k
or similar? -v is pretty important parameter. Without -v all kind of artifacts will show up.
You might add dither -S. Though as far as I can see the src takes care on aliasing, if you don't specifiy -a.
e.g.
rate -v -p 25 -b 93 192k
or similar? -v is pretty important parameter. Without -v all kind of artifacts will show up.
You might add dither -S. Though as far as I can see the src takes care on aliasing, if you don't specifiy -a.
Attachments
Last edited:
Those lines on the spectrogram are not artifacts but missing samples due to apparent bugs in the integration code. I will write the alsa-lib plugin from scratch anyway (using plain libsoxr), ironing out these inconsistencies.
The code does not use sox. Libsoxr is a standalone library inspired by the sox rate effect, similar to what the foobar sox plugin does. It does not offer dither, as of now. It was created by audacity team. Just check libsoxr out in google.
I do not think dither should be part of the actual rate conversion code. Its proper place is in the format conversion code.
You can go ahead and build it into the alsa-lib format conversion code, used e.g. git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_rate.c . It would require quite a redesign though.
IMO dither for playback chain is not that important anymore. It makes sense only for decimation to fewer than 24 bits (just like sox does SourceForge - sox/sox/blob - src/sox.c ), while most modern audio interfaces support 24 bit already, avoiding the int16 conversion along the whole chain (in my modified pcm_rate.c code).
There are people and companies dithering even 24/96 to clean up potential mess in the non audible regions.
Upper region mess might get spit back into the audible regions.
And sorry. Alsa development is not my area of involvement.
I'm still a happy user of Alsa and concentrate on different stuff.
BTW. Many people consider the IZOTOPE SRC the best. I still havn't been able to compare Sox and Izotope. Has anybody else around here managed??
Upper region mess might get spit back into the audible regions.
And sorry. Alsa development is not my area of involvement.
I'm still a happy user of Alsa and concentrate on different stuff.BTW. Many people consider the IZOTOPE SRC the best. I still havn't been able to compare Sox and Izotope. Has anybody else around here managed??
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.