Hi folks.
I am playing around with a M-Audio Transit. I am using the Toslink interface towards a TAS5706 based full-digital amplifier, which I am currently testing.
I have also written a small how-to to get the Transit working under Linux. You'll find it in the Wiki. (I btw already put some effort into updating all Wiki pages. It's not finished yet. But it is getting better every day.)
Now: The M-Audio driver is working fine so far at 44.1/16 .
But how do I control the card? E.g. to set latencies, buffers sample-rates etc. I need some kind of host application or command-
set to set resp. tweak the parameters.
Does somebody have a clue how to tackle this issue?
Cheers
\Klaus
I am playing around with a M-Audio Transit. I am using the Toslink interface towards a TAS5706 based full-digital amplifier, which I am currently testing.
I have also written a small how-to to get the Transit working under Linux. You'll find it in the Wiki. (I btw already put some effort into updating all Wiki pages. It's not finished yet. But it is getting better every day.)
Now: The M-Audio driver is working fine so far at 44.1/16 .
But how do I control the card? E.g. to set latencies, buffers sample-rates etc. I need some kind of host application or command-
set to set resp. tweak the parameters.
Does somebody have a clue how to tackle this issue?
Cheers
\Klaus
I do not think there are special controls for M-Audio USB cards in Alsa. Concerning the buffers, I would assume M-Audio cards use the same facilities as other regular USB cards - your field of specialization 
Take a loot at the source files for m-audio usb cards:
http://git.alsa-project.org/?p=alsa...fb7c2276872a05f40a07a0ed57d0b57357e8e;hb=HEAD
http://git.alsa-project.org/?p=alsa...726c049c6c1f5d7b891e2e25bcd62ff934e40;hb=HEAD
Take a loot at the source files for m-audio usb cards:
http://git.alsa-project.org/?p=alsa...fb7c2276872a05f40a07a0ed57d0b57357e8e;hb=HEAD
http://git.alsa-project.org/?p=alsa...726c049c6c1f5d7b891e2e25bcd62ff934e40;hb=HEAD
I looked them up. I've been in there before. The quirks seem to be the entry into the config.
(I've implemented a very basic quirk for the Benchmark DAC1 before and it even worked).
However. I am not really aware how these work in general and how they can be used.
I would need the internal address and parameter structures of
the M-Audio Transit first - right? Then I'd need an application to set these? So it is not that easy. It shouldn't be too difficult to send a plain Ascii string over the interface ( I'd need to figure that out, too)
I need to read Takashi Iwai's paper on driver devlopment.
Now I am entering the depth of driver development.
Perhaps that's what I should do anyhow.
Cheers
(I've implemented a very basic quirk for the Benchmark DAC1 before and it even worked).
However. I am not really aware how these work in general and how they can be used.
I would need the internal address and parameter structures of
the M-Audio Transit first - right? Then I'd need an application to set these? So it is not that easy. It shouldn't be too difficult to send a plain Ascii string over the interface ( I'd need to figure that out, too)
I need to read Takashi Iwai's paper on driver devlopment.
Now I am entering the depth of driver development.
Perhaps that's what I should do anyhow.
Cheers
does anyone know if this can be implemented to Linux platform?
http://www.audioasylum.com/forums/pcaudio/messages/3/32581.html
http://www.audioasylum.com/forums/pcaudio/messages/3/32581.html
ackcheng said:
I do not see anything special. ASIO = alsa, the secret rabbit upsampling library is multiplatform, can be used as plugin in the built-in alsa resampler (e.g. dmix).
http://64.233.183.104/search?q=cach...p=47973+secret+rabbit+alsa&hl=cs&ct=clnk&cd=5
http://blog.flameeyes.eu/articles/2007/02/01/a-little-hint-for-alsa-hda-users
Individual parameters of libsamplerate could be tweaked in code or perhaps in the config files.
Ad AWE - using 64-bit system avoids the 3GB memory limit per linux process (2GB in windows)
correct me if I am wrong but my understanding is that AWE allows a certain part of RAM dedicated for audio. This way, this physical part of RAM is untouched by other program and can be sure that the signal path from the RAM to the sound card is the same every single time? If we just create a Ram disk, this can occupy different part of the physical RAM everytime we load the programs.
This is similar to someone who claims that placing music files at different folders in the same hard disk actually sound different?
This is similar to someone who claims that placing music files at different folders in the same hard disk actually sound different?
The Windows policy Lock Pages in Memory option is disabled by default. This privilege must be enabled to configure Address Windowing Extensions (AWE). This policy determines which accounts can use a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk.
That sounds similar to using something like
@audio - memlock 512000
@audio - rtprio 25
in /etc/security/limits.conf to allow members of the audio group to use
memlock (MCL_CURRENT | MCL_FUTURE); to lock pages into RAM.
The second line above allows members of group audio to use the posix realtime scheduling to effectively opt out of normal process scheduling and preemption.
If you want a fixed location for a buffer in physical ram (Why?), you can pass the kernel mem=... to restrict the kernel to using the appropriate amount of memory, then access the rest via /dev/kmem or the like for your buffer. Some very fast data acquisition cards had to play this game back in the day, but it is vast overkill for audio type stuff.
I don't see any problem with writing something like the above project, except that I don't really see the point.
Regards, Dan.
@audio - memlock 512000
@audio - rtprio 25
in /etc/security/limits.conf to allow members of the audio group to use
memlock (MCL_CURRENT | MCL_FUTURE); to lock pages into RAM.
The second line above allows members of group audio to use the posix realtime scheduling to effectively opt out of normal process scheduling and preemption.
If you want a fixed location for a buffer in physical ram (Why?), you can pass the kernel mem=... to restrict the kernel to using the appropriate amount of memory, then access the rest via /dev/kmem or the like for your buffer. Some very fast data acquisition cards had to play this game back in the day, but it is vast overkill for audio type stuff.
I don't see any problem with writing something like the above project, except that I don't really see the point.
Regards, Dan.
Do you say that all 270x based chips resample internally, even for USB > I2S data, or only when used as a DAC?
There are a lot of DAC's around which use PCM2706/7 for USB > I2S which would mean, that all of them are lossy when used as USB?
It's bad that the more I dig into perfect DAC's I find no way out. At the moment, I think the only possibilities are:
- Asus EEE PC with highly modded linux kernel + USB DAC
- Chinese I2S port on Zhoulu D3
- some experimental DAC, like ethernet DAC + mpd
- CrazyT from BD-Design, have a look, they really seem to understand what they do and they developed their own software for sending data to the DAC (like ethernet DAC), but it's not a DIY budget...
http://www.bd-design.nl/contents/en-us/d168.html
There are a lot of DAC's around which use PCM2706/7 for USB > I2S which would mean, that all of them are lossy when used as USB?
It's bad that the more I dig into perfect DAC's I find no way out. At the moment, I think the only possibilities are:
- Asus EEE PC with highly modded linux kernel + USB DAC
- Chinese I2S port on Zhoulu D3
- some experimental DAC, like ethernet DAC + mpd
- CrazyT from BD-Design, have a look, they really seem to understand what they do and they developed their own software for sending data to the DAC (like ethernet DAC), but it's not a DIY budget...
http://www.bd-design.nl/contents/en-us/d168.html
Hi folks.
The only way to disconnect the DAC from the PC jitter mess is to run
asynchronous over any kind of communication media.
The receiver controls the flow and buffers the stream in this case.
If you look at the ethernet boxes a la Squeezebox - we do not talk about realtime datastreams any longer, they buffer the stream and the FPGA is kind of resending it. You won't face any bit-error issues on the ethernet.
This you'll find implemented on e.g. EMU0404, Wavelength Async DACs for USB or Squeezebox ( or similar) for ethernet equipment.
If you look at BD-Design. Bert justed jumped on that train.
Buffering the datastream in a kind of async mode is nothing new.
The BD-design solution is a propriatary solution. You need to have
a special BD-Design player.
If you run such an ethernet box you won't hear any changes done on the PC. Of course the issues are now moved further down the stream.
But for sure it is easier to solve these down there.
But there are certain shortcomings:
Most implementations are 44.1 only.
High latency.
2 channel only
I am just playing around to build a streaming client with MusicPlayerdaemon and PulseAudio.
I also just connected a EMU USB 0404 to see how this works.
( You need to update it's firmare via Windows first. Makes the 0404 play 44.1 by default. Of course you're limited by 44.1 for the time being.)
BTW: I just finished my desktop rig: The new Adam A5 speakers (with stands) and the EMU 0404 USB. Now I spend even more hours at the PC. The sound is just great.
Cheers
The only way to disconnect the DAC from the PC jitter mess is to run
asynchronous over any kind of communication media.
The receiver controls the flow and buffers the stream in this case.
If you look at the ethernet boxes a la Squeezebox - we do not talk about realtime datastreams any longer, they buffer the stream and the FPGA is kind of resending it. You won't face any bit-error issues on the ethernet.
This you'll find implemented on e.g. EMU0404, Wavelength Async DACs for USB or Squeezebox ( or similar) for ethernet equipment.
If you look at BD-Design. Bert justed jumped on that train.
Buffering the datastream in a kind of async mode is nothing new.
The BD-design solution is a propriatary solution. You need to have
a special BD-Design player.
If you run such an ethernet box you won't hear any changes done on the PC. Of course the issues are now moved further down the stream.
But for sure it is easier to solve these down there.
But there are certain shortcomings:
Most implementations are 44.1 only.
High latency.
2 channel only
I am just playing around to build a streaming client with MusicPlayerdaemon and PulseAudio.
I also just connected a EMU USB 0404 to see how this works.
( You need to update it's firmare via Windows first. Makes the 0404 play 44.1 by default. Of course you're limited by 44.1 for the time being.)
BTW: I just finished my desktop rig: The new Adam A5 speakers (with stands) and the EMU 0404 USB. Now I spend even more hours at the PC.
The sound is just great.Cheers
OK, I start to understand.
The cheap way is to use common synchronous USB DACs and prepare the PC as far as we can. For example using Ubuntu Studio realtime kernel and disable every background daemon and use uncompressed wav and ramdrive. It's not quite comfortable, but practically it produces the lowest jitter a PC architecture can produce, and if for example using a dedicated moving part less mini-ITX box or Asus EEE PC with SSD, and start only a mpd on it, that could work like a Sqeezebox with USB port, using mpd network streaming. Do you know anything about if OS X could have as low jitter as a dedicated linux box could produce, or not at all?
The expensive way is to buy a high-end product from BD-Design or Wavelength, where they engineered a firmware and some custom solution for actually streaming the data from the PC to the DAC, and timing it with a high precisision clock. I prefer the BD-Design solution, because I don't know why, but all the "saying-to-be-bit-perfect" solutions on XP and Vista sound different. Why is there a difference between foobar's ASIO and J Media's ASIO? Why do I have 3 different settings on the high-end Vista player (I don't know the name, but it's the alternative approach to this topic) I don't want any settings for different sound on a transport!
So I beleive that if BD-Design sends redbook CD data to the DAC, it needs custom software, but that's the way of implementing things right. Not some 5 different sounding bit-perfect choice.
The wavelength's Windows part has the same limitations no matter what they do, when using the DAC as Windows' soundcard. Why do I have to set the volume at 50% and download different ASIO drivers and choose different ASIO players, when I bought a $7500 DAC. OK, it seems they concentrated on the mac part, and they prefer it over windows. Actually they prefer the G4 mac, as I found from the Brick's review.
The cheap way is to use common synchronous USB DACs and prepare the PC as far as we can. For example using Ubuntu Studio realtime kernel and disable every background daemon and use uncompressed wav and ramdrive. It's not quite comfortable, but practically it produces the lowest jitter a PC architecture can produce, and if for example using a dedicated moving part less mini-ITX box or Asus EEE PC with SSD, and start only a mpd on it, that could work like a Sqeezebox with USB port, using mpd network streaming. Do you know anything about if OS X could have as low jitter as a dedicated linux box could produce, or not at all?
The expensive way is to buy a high-end product from BD-Design or Wavelength, where they engineered a firmware and some custom solution for actually streaming the data from the PC to the DAC, and timing it with a high precisision clock. I prefer the BD-Design solution, because I don't know why, but all the "saying-to-be-bit-perfect" solutions on XP and Vista sound different. Why is there a difference between foobar's ASIO and J Media's ASIO? Why do I have 3 different settings on the high-end Vista player (I don't know the name, but it's the alternative approach to this topic) I don't want any settings for different sound on a transport!
So I beleive that if BD-Design sends redbook CD data to the DAC, it needs custom software, but that's the way of implementing things right. Not some 5 different sounding bit-perfect choice.
The wavelength's Windows part has the same limitations no matter what they do, when using the DAC as Windows' soundcard. Why do I have to set the volume at 50% and download different ASIO drivers and choose different ASIO players, when I bought a $7500 DAC. OK, it seems they concentrated on the mac part, and they prefer it over windows. Actually they prefer the G4 mac, as I found from the Brick's review.
erozsolt said:
You never know what is happening in the Windows internals. Did you check the bit-perfection of each setup yourself? I kind of do not understand why people spend so much time analyzing the windows sound stack which changes for each windows version. If they want consistent top-quality and full control over their sound stack, they have complete source code of linux available.
If BD provides complicated drivers, then do not buy it
I personally would not go for an expensive long-lasting device with proprietary drivers - will the manufacturer provide quality drivers for older models for the upcoming Windows 8?Asynchronous USB (e.g. E-MU 0404) is technically "the way of implementing things right" too. I guess BD used the bulk mode so that they can utilize the bandwidth of USB 2.0 (and have e.g. an external USB drive hooked to the same USB line). The bandwidth of the old USB 1.0 has almost no spare capacity when running at higher sample rates and the sound card cannot share the port for proper performance (e.g. via a USB hub).
Hi folks.
Somebody mentioned earlier the Music Player Daemon as a nice alternative player.
I just tried it, because I was not really happy with Pulseaudio. (Background: I am in the process of setting up my home-audio/multimedia-network properly. I want to avoid the shortcomings of Squeezebox and similar devices.)
In fact MPD is a nice no-frill player alternative. And it sounds really good.
A very nice functionality is its client/server capability. This makes it possible to play your music from any place/client in the network and locally quiet easily.
You can even shutdown your remote client while playing back. The daemon keeps playing on the audio-machine.
I've chosen Minion a Firefox Add-On ( officially available in the Firefox Add-On database) as my prime MPD Front-End.
Just try it. Within 10 minutes you'll enjoy quite a nice setup. (Even my wife loves the easy handling!)
I put everything down which is required for a basic setup. Have a look over here:
http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+MusicPlayerDaemon
Enjoy
Somebody mentioned earlier the Music Player Daemon as a nice alternative player.
I just tried it, because I was not really happy with Pulseaudio. (Background: I am in the process of setting up my home-audio/multimedia-network properly. I want to avoid the shortcomings of Squeezebox and similar devices.)
In fact MPD is a nice no-frill player alternative. And it sounds really good.
A very nice functionality is its client/server capability. This makes it possible to play your music from any place/client in the network and locally quiet easily.
You can even shutdown your remote client while playing back. The daemon keeps playing on the audio-machine.
I've chosen Minion a Firefox Add-On ( officially available in the Firefox Add-On database) as my prime MPD Front-End.
Just try it. Within 10 minutes you'll enjoy quite a nice setup. (Even my wife loves the easy handling!)
I put everything down which is required for a basic setup. Have a look over here:
http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+MusicPlayerDaemon
Enjoy
Hi folks.
I added a new Wiki for the ones interested to update their ALSA to the latest revision.
I think especially ALSA is worthwhile to keep up2date, which won't be the case if you
wait for distro updates. Without it my EMU 0404USB still wouldn't work.
It is a quick and dirty solution - phofman I hear you - but at least it works.
If all applications are gonna work 100% flawless - No idea.
Of course it is always better to recompile the applications based on the new libraries.
However usually it works without it.
http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+ALSAManualInstall
Drop me a mail if you want the file.
Cheers
I added a new Wiki for the ones interested to update their ALSA to the latest revision.
I think especially ALSA is worthwhile to keep up2date, which won't be the case if you
wait for distro updates. Without it my EMU 0404USB still wouldn't work.
It is a quick and dirty solution - phofman I hear you
- but at least it works. If all applications are gonna work 100% flawless - No idea.
Of course it is always better to recompile the applications based on the new libraries.
However usually it works without it.
http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+ALSAManualInstall
Drop me a mail if you want the file.
Cheers
I always wondered why not the other way around?
In my theory, a perfect system is a headless mpd server with no user interaction, just a config file to start playing back an icecast 44.1/16 WAV stream from a local computer, looking for the stream every 5 seconds. No input, no configuration, just an icecast stream over local network. I think a minimal linux for mpd and realtime kernel could be around 50 MB max.
On the client (stream server) side, everyone can do what he likes. For example use foobar or winamp or any fancy media player capable of icecast streaming. For foobar and winamp, there is Edcast DSP plugin.
http://www.oddsock.org/tools/edcast/
That way there is almost no processing and definately no HDD or CD seeking on the linux box. You can even terminate almost all other processes, since there is no need for X or any user interaction. Everyone can use what player he is used to.
In my theory, a perfect system is a headless mpd server with no user interaction, just a config file to start playing back an icecast 44.1/16 WAV stream from a local computer, looking for the stream every 5 seconds. No input, no configuration, just an icecast stream over local network. I think a minimal linux for mpd and realtime kernel could be around 50 MB max.
On the client (stream server) side, everyone can do what he likes. For example use foobar or winamp or any fancy media player capable of icecast streaming. For foobar and winamp, there is Edcast DSP plugin.
http://www.oddsock.org/tools/edcast/
That way there is almost no processing and definately no HDD or CD seeking on the linux box. You can even terminate almost all other processes, since there is no need for X or any user interaction. Everyone can use what player he is used to.
A $50 NSLU2 could be the perfect high-end USB transport?
http://matrix108.wordpress.com/2007/08/26/internet-radio-on-the-slug/
Same with an Asus 500g, running OpenWRT
http://www.equinoxefr.org/post/2008/06/15/bricolage-autour-d’un-routeur-asus-wl500gp-partie-2/
USB-audio on OpenWRT wiki:
http://wiki.openwrt.org/UsbAudioHowto
http://matrix108.wordpress.com/2007/08/26/internet-radio-on-the-slug/
Same with an Asus 500g, running OpenWRT
http://www.equinoxefr.org/post/2008/06/15/bricolage-autour-d’un-routeur-asus-wl500gp-partie-2/
USB-audio on OpenWRT wiki:
http://wiki.openwrt.org/UsbAudioHowto
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.