Teralink X2

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
As my USB dac uses the same Tenor chip as the X2, I suspect Alsa users may see the same issue, and may have a solution for me ;)

When playing flac 96/24 files, eg. using mplayer, the output is truncated to 16 bits. This is the output of mplayer when playing the Linn 24-bit sample:

Playing recit24bit.flac.
Audio only file format detected.
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 88200 Hz, 2 ch, s32le, 2401.6 kbit/42.54% (ratio: 300196->705600)
Selected audio codec: [ffflac] afm: ffmpeg (FFmpeg FLAC audio)
==========================================================================
[AO_ALSA] Format s32le is not supported by hardware, trying default.
AO: [alsa] 96000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...

Notice that the s32le (24 bits within 4 bytes) is output to the card in s16le (16 bits). The card is capable of s24_3le (24 bits in 3 bytes), according to the alsacap output. With pulseaudio, I have observed that pulse correctly outputs the same audio stream in s24_3le to the dac. As the X2 (and ESI and Stello) use the same Tenor USB receiver, my guess is that Alsa would be doing the same on these dacs... :(
 
resample-method = speex-float-2 (or src-sinc-medium-quality if you have a fast CPU)
default-sample-format = s24le
default-sample-rate = 96000

3. If pulse is already running,
$ pulseaudio -k
will kill / restart pulse, using your new settings.

does not work here...
my src is getting 44.1...

I am pretty shure this worked in 8.04...
 
also tried this:
found it here: 24/96 Output in Ubuntu 10.04 t - D1info - UNgzmk3X - Pastebin.com

24/96 Output in Ubuntu 10.04 to the Maverick D1


Forewarning: This is not meant for the linux illiterate, i've tried to make this guide as newbie friendly as possible, but some knowledge of the command line is expected.


Step one is to disable Pulseaudio from autospawning on login, we won't uninstall it, but it won't start up on login anymore, leaving you just ALSA.

To do this, run "sudo nano /etc/pulse/client.conf" in terminal and uncomment the line "; autospawn = yes" and change yes to no, leaving you with: " autospawn = no" then save that and exit.

Next, make sure "libasound2-plugins" in installed via synaptic package manager.

Then, you open your favorite editor again, gedit or nano for instance, and create a file named ".asoundrc" (minus quotations) and inside paste this code:

pcm.!default {
type hw
card 1
device 0

}
pcm.rate_convert {
type plug
slave {
pcm "hw:1,0"
rate 96000
}

}

defaults.pcm.rate_converter "samplerate_best"
*********************

my hardware:

**** Lijst van PLAYBACK hardware-apparaten ****
kaart 0: Intel [HDA Intel], apparaat 0: ALC1200 Analog [ALC1200 Analog]
Sub-apparaten: 1/1
Sub-apparaat #0: subdevice #0
kaart 0: Intel [HDA Intel], apparaat 1: ALC1200 Digital [ALC1200 Digital]
Sub-apparaten: 1/1
Sub-apparaat #0: subdevice #0
kaart 1: Audio [TeraDak 96K USB Audio], apparaat 0: USB Audio [USB Audio]
Sub-apparaten: 0/1
Sub-apparaat #0: subdevice #0
kaart 1: Audio [TeraDak 96K USB Audio], apparaat 1: USB Audio [USB Audio #1]
Sub-apparaten: 1/1
Sub-apparaat #0: subdevice #0


I cannot find a way to get 96K in my SRC...

anybody?

kind regards,

Tony
:confused::confused::confused:
 
pcm.!default {
type hw
card 1
device 0

}
pcm.rate_convert {
type plug
slave {
pcm "hw:1,0"
rate 96000
}

}

defaults.pcm.rate_converter "samplerate_best"
*********************


I cannot find a way to get 96K in my SRC...

You have defined a new pcm device called rate_convert which converts to 96kHz, but your default device is still the direct output to HW (see the default section). If you want to use the new device, either reconfigure your audio applications to use the new device, or redefine the default device instead:
Code:
pcm.!default rate_convert
 
Playing recit24bit.flac.
Audio only file format detected.
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 88200 Hz, 2 ch, s32le, 2401.6 kbit/42.54% (ratio: 300196->705600)
Selected audio codec: [ffflac] afm: ffmpeg (FFmpeg FLAC audio)
==========================================================================
[AO_ALSA] Format s32le is not supported by hardware, trying default.
AO: [alsa] 96000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...

Notice that the s32le (24 bits within 4 bytes) is output to the card in s16le (16 bits). The card is capable of s24_3le (24 bits in 3 bytes), according to the alsacap output. With pulseaudio, I have observed that pulse correctly outputs the same audio stream in s24_3le to the dac. As the X2 (and ESI and Stello) use the same Tenor USB receiver, my guess is that Alsa would be doing the same on these dacs... :(

The conversion to 16bits is not a decision of alsa, but that of mplayer. See SourceForge - mplayer-ww/mplayer-ww/blob - libao2/ao_alsa.c . Mplayer asks alsa if the card supports the original format (s32le in your case) by calling alsa API snd_pcm_hw_params_test_format . Your card does not support this format and mplayer converts the format to its compiled-in default s16le.

The problem with mplayer is this fixed default. Unfortunately mplayer does not ask the card about actual supported values and blindly converts to 16bits instead. Many cards (e.g. Envy24) support s32le only and the only way to make them work with mplayer is using the plug plugin which converts that default s16le back to s32le. Of course details are lost for files with resolution above 16 bits. Perhaps time to fix that :)
 
Thanks phofman! I was asking around the alsa forum, and they pointed to *exactly* the same code on ao_alsa.c for mplayer.

I have written a patch to that code that first tests if the card will accept s24le. If this fails, then it will use s16le. It's less than 10 lines, I think, and I will post it to the mplayer mailing list.

The patch seems to work on a USB card that takes only s16le, as well as on-board audio cards that take s16le + s32le, and USB card that takes s16le + s24_3le. Hopefully it means mplayer audio is less compromised.
 
Thanks phofman! I was asking around the alsa forum, and they pointed to *exactly* the same code on ao_alsa.c for mplayer.

I have written a patch to that code that first tests if the card will accept s24le. If this fails, then it will use s16le. It's less than 10 lines, I think, and I will post it to the mplayer mailing list.

The patch seems to work on a USB card that takes only s16le, as well as on-board audio cards that take s16le + s32le, and USB card that takes s16le + s24_3le. Hopefully it means mplayer audio is less compromised.

Great, it will definitely help, thanks. Nevertheless, have you considered making the code more universal, e.g. for 32bit cards? If you want to play with it, you might want to look at source code of the plug plugin git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_plug.c . If the current format is not supported, the plugin tries to find the nearest higher-resolution supported format (for (w1 = w; w1 <= 32; w1++)). Only after that it resorts to finding the nearest lower-resolution one (for (w1 = w - 1; w1 > 0; w1--)). Something like this would be the universal solution to any soundcard.

OR perhaps a better solution would be if the plug plugin listed all the known formats in hw_params, therefore the reformating/resampling code in mplayer would never kick in when the plug plugin was used in soundcard definition (-ao alsa:device=plughw=0). I will ask on alsa-devel mailing list.
 
Great, it will definitely help, thanks. Nevertheless, have you considered making the code more universal, e.g. for 32bit cards? If you want to play with it, you might want to look at source code of the plug plugin git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_plug.c . If the current format is not supported, the plugin tries to find the nearest higher-resolution supported format (for (w1 = w; w1 <= 32; w1++)). Only after that it resorts to finding the nearest lower-resolution one (for (w1 = w - 1; w1 > 0; w1--)). Something like this would be the universal solution to any soundcard.

OR perhaps a better solution would be if the plug plugin listed all the known formats in hw_params, therefore the reformating/resampling code in mplayer would never kick in when the plug plugin was used in soundcard definition (-ao alsa:device=plughw=0). I will ask on alsa-devel mailing list.

Thanks again. I did not consider the case of S24_LE audio going to a card only supporting S32_LE. I've added another 3-4 lines to ao_alsa.c, and now S24_LE audio (eg. 24-bit .wav) will not be truncated, but formatted up to S32_LE.

I also found this issue on the mplayer pulse option, and a very simple change to maps[], putting the 32-bit formats before 16-bit ;) does the trick. I presume oss and other drivers may have the same issue on mplayer, but I will just focus on alsa and pulse.. I will post to mplayer-user mailing list, after some testing.
 
Thanks again. I did not consider the case of S24_LE audio going to a card only supporting S32_LE. I've added another 3-4 lines to ao_alsa.c, and now S24_LE audio (eg. 24-bit .wav) will not be truncated, but formatted up to S32_LE.

I also found this issue on the mplayer pulse option, and a very simple change to maps[], putting the 32-bit formats before 16-bit ;) does the trick. I presume oss and other drivers may have the same issue on mplayer, but I will just focus on alsa and pulse.. I will post to mplayer-user mailing list, after some testing.

I was using an older mplayer without s24le support (SourceForge - mplayer-ww/mplayer-ww/blob - libao2/ao_alsa.c was missing) and that got me confused. The newer mplayer works fine with the plug plugin defined as alsa device (-ao alsa:device=plughw=0) and 24bit files. IMO this is a cleaner solution than re-implementing its core functions in mplayer directly.
 
I bought one of this board from ebay (see attachment), it's based on Tenor TE7022L and i tried it with Ubuntu Linux 10.04.

Result from 'aplay -l':
Code:
card 1: Audio [TeraDak 96K USB Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Audio [TeraDak 96K USB Audio], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Result from 'cat /proc/asound/card1/stream0':
Code:
TeraDak Electronics TeraDak 96K USB Audio at usb-0000:00:1d.0-2, full speed : USB Audio

Playback:
  Status: Stop
  Interface 3
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 3 OUT (ADAPTIVE)
    Rates: 8000, 16000, 32000, 44100, 48000, 96000
  Interface 3
    Altset 2
    Format: S24_3LE
    Channels: 2
    Endpoint: 3 OUT (ADAPTIVE)
    Rates: 8000, 16000, 32000, 44100, 48000, 96000

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 2 IN (ADAPTIVE)
    Rates: 8000, 16000, 32000, 44100, 48000, 96000
  Interface 2
    Altset 2
    Format: S24_3LE
    Channels: 2
    Endpoint: 2 IN (ADAPTIVE)
    Rates: 8000, 16000, 32000, 44100, 48000, 96000
Result from 'cat /proc/asound/card1/stream1':
Code:
TeraDak Electronics TeraDak 96K USB Audio at usb-0000:00:1d.0-2, full speed : USB Audio #1

Playback:
  Status: Stop
  Interface 3
    Altset 3
    Format: S16_LE
    Channels: 2
    Endpoint: 3 OUT (ADAPTIVE)
    Rates: 48000

It's all OK and i can play 96/24 sound with this board using device 0 (as we can see from what is reported above device 1 can only do 48/16).
The only doubt is that in alsamixer i have a PCM slide that control the volume of the spdif out and i have to verify that at full volume i got a bit perfect out.
For now i didn't verify this because i have only audio boards with TOSLINK spdif input, i will build a little converter to do the test and then i will report the results.

Ciao
Andrea
 

Attachments

  • Teralink.jpg
    Teralink.jpg
    65.6 KB · Views: 531
I bought one of this board from ebay (see attachment), it's based on Tenor TE7022L and i tried it with Ubuntu Linux 10.04.

Ciao
Andrea

hi I did exact the same as you...everything higher then 48000 gives me distortion...tried s16le, s24le, s32le...always the same.
now it is playing very nice @s24le/48000

tried it in windows 7 as well...same thing everything higher then 48000 distortion...

I think it is the teradak....

I have a brandnew computer since last week (HP HPE320 with optical out and internal (lousy) hd audio...) but I can manage to let it play in ubuntu and windows 7 @24/96000...

I think I will look for a real soundcard with optical out @192000...

sugestions?


kind regards,

Tony
 
hi I did exact the same as you...everything higher then 48000 gives me distortion...tried s16le, s24le, s32le...always the same.
now it is playing very nice @s24le/48000

tried it in windows 7 as well...same thing everything higher then 48000 distortion...

I think it is the teradak....

I have a brandnew computer since last week (HP HPE320 with optical out and internal (lousy) hd audio...) but I can manage to let it play in ubuntu and windows 7 @24/96000...

I think I will look for a real soundcard with optical out @192000...

sugestions?


kind regards,

Tony

Hi,
maybe there was a misunderstanding due to my bad English knowledge but i don't ear distortion at 96000/S24_3LE.
I only have a little doubt about the bit perfectness of the device 0 of this card and till now i had no time to test this, when i will do it i will let you know.

Ciao
Andrea
 
Hi,
i built a little coax -> optical spdif interface to test my card and i can say that it is bit perfect for 48/16 and 96/16.
I have tested it with "aplay" on the card under test and "arecord" on another card with optical spdif in, then i compared the original wav file with the recorded one with "wavdiff" (http://axel-sommerfeldt.de/wavdiff001123.zip).
Obviously this test gives bit perfect results only with the PCM volume control on "alsamixer" for the card under test at 100%.
I couldn't test the card with 48/24 and 96/24 wav because wavdiff works only with 16 bit wav files.
I would like to know if someone knows another program to compare wav files (similar to wavdiff - it handles files with different length and different silence offset on the head) that can cope with 24 wav files.

Ciao
Andrea
 
Andrea,

I played with testing bit-perfectness quite a lot and could not find any automated tool. wavdiff was OK (for 16 bits), but it could not align wavs with minor distortions at the beginning (not all recorded tracks from spdif-in started with zero samples). I ended up truncating and aligning the two tracks in audacity (with a bit of practice it does not take more than two minutes). Subsequent comparison - subtracting the aligned wavs is straightforward in SoX.

If you are fine with wavdiff, its C code is nice and clean, it should not be difficult to modify. Perhaps :)
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.