Re: Higher quality dmix resampling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> >> If it's the latter (as usually is on modern systems), then its just
>> >> the input interface that changes, you're goin' trough ALSA anyway.
>>
>> Also, I should mention something that contradicts this.  When I define
>> a "format" for dmix in /etc/asound.conf that my DAC doesn't like, no
>> ALSA apps will play sound.  However, if I choose to output via OSS in
>> those apps, I get sound.  Here is an example of an asound.conf that
>> causes apps set to ALSA to not play sound at all, and apps set to OSS
>> to play sound perfectly as always:
>
> well, that does only mean that the OSS-emulation interface does not
> obey asound.conf (and/or .asoundrc) rules but use some different
> "general" setup. This of course makes perfect sense, as OSS provided
> only a simple device file interface: there would be no reason for the
> emulated OSS interface to provide anything different...
>
> Thus, I would say that what this means is that the underlying low-
> level driver (at least in some conditions) does work, but either the
> default setup on your installation is somewhat screwed or the driver
> does not work properly in all possible modes (that is, yet another
> snd_hda* bug...).

Just to avoid confusion, mine is a USB DAC and it uses snd_usb_audio.
hda was the card that blog post mentioned.

I have another USB DAC which uses the same driver on the same system
and does not produce static.  I should also mention that the static
varies from very quiet to loud depending on which file I'm playing.

> BTW, since I'm here I'm attaching the .asoundrc I'm using on my HTPC.
> I'm not 100% sure whether it's completely correct, but for sure playing
> to the default device (which goes to the on-board HDA) as well as to the
> HD192 & HD176 does work perfectly. I'm also quite sure that indeed ALSA
> does obey the "defaults.pcm.rate_converter" setting (yes, also for the
> HDnnn "resampling inputs" to the Juli@).

Another thing that makes me wonder about defaults.pcm.rate_converter
on my system is the fact that using samplerate_best in asound.conf
uses no CPU, but when I use it in mpd it maxes the CPU.

> Removing all the (still "experimental") parts used to "distribute" the
> signal to various outputs (I did that mainly for testing purpouses...)
> and the "duplicate" parts for different settings, all that matters is
> basically just this:
>
> # ~/.asoundrc
> defaults.pcm.rate_converter "speexrate_best"
>
> ############################################################################
> # Give our card(s) some friendly aliases.
> #
> pcm.Juli12 "front:CARD=Juli,DEV=0"
> #
> # This is Julia channels 1&2 (analog stereo & tapped I2S out)
> # device name "front:CARD=Juli,DEV=0" obtained with "aplay -L"

I get:

# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: USBDAC [Proton USBDAC], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

I suppose the next thing to do is try a LiveCD.  I'll do that ASAP.

- Grant

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user


[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux