[alsa-devel] [PATCH 2/2] snd-oxygen: Fixes for the Xonar DG card
Roman Volkov
v1ron at mail.ru
Wed Nov 20 14:15:23 CET 2013
В Wed, 20 Nov 2013 13:29:18 +0100
Clemens Ladisch <clemens at ladisch.de> пишет:
> Roman Volkov wrote:
> > Clemens Ladisch <clemens at ladisch.de> пишет:
> >> Roman Volkov wrote:
> >>> + * 128kHz doesn't work for CS4361 (multichannel playback)
> >>
> >> Why do you expect 128 kHz to work?
> >
> > 128kHz will not work because ...
>
> ... the CMI8788 does not support 128 kHz in the first place.
>
> > And perhaps my anti-pop delay of 1 second is too long.
>
> The Windows driver uses 2.5 seconds.
>
> >> Is the reset pin actually connected? Does the Windows driver do
> >> this?
> >
> > Should be, otherwise this is bad design.
>
> This driver is not for a theoretical, optimally designed card; it is
> for the actual card that Asus builds. If the Windows driver does not
> touch the reset pin, we should not do this either (because it might be
> connected to the self-destruct trigger).
>
> > sometimes (rarely) I get completely distorted sound when I power up
> > the Windows machine.
>
> After a cold boot?
>
> This also happened for some other Xonar card when the Linux driver did
> things differently and did not reset these settings when shutting
> down.
>
> >> Use mdelay() only when sleeping is not possible; use msleep()
> >> instead.
> >
> > msleep() is not recommended for small delays (1ms-20ms).
>
> Only because it isn't very accurate. But using mdelay() is even worse
> because it busy-loops.
>
> >>> + case PLAYBACK_DST_20_CH:
> >>> + case PLAYBACK_DST_40_CH:
> >>> + case PLAYBACK_DST_51_CH:
> >>
> >> Why is it necessary to differentiate between those? There should
> >> be no mixer control; the driver can automatically detect what
> >> format is used. And this should not make any difference because
> >> the unused channels will be silent anyway.
> >
> > Just as in the windows driver.
>
> This is not necessarily a reason to implement the same in the Linux
> driver, especially if it's not required by the actual hardware, and
> reduces usability.
>
> > Should I change this to "HP\HP FP\Speakers"?
>
> Yes.
>
> >>> +/* Put the codec into low power mode, disable audio output, save
> >>> registers */
> >>
> >> Does the Windows driver implement this?
> >
> > I don't know. Linux docs says I should put my hardware into low
> > power mode and I do that.
>
> As far as I know, none of the Xonar cards have any real power-saving
> functionality; they rely on the entire PCI slot being powered down.
>
> For practical purposes, suspend/resume just means that you have to
> restore the registers.
>
> >>> - .function_flags = OXYGEN_FUNCTION_SPI,
> >>> + .function_flags = OXYGEN_FUNCTION_SPI |
> >>> OXYGEN_FUNCTION_ENABLE_SPI_4_5,
> >>
> >> Why?
> >
> > Because this just works and as in the Windows driver.
>
> If nothing is connected to those pins, it doesn't matter. This code
> in the Windows driver probably was just copy/pasted from the D2 code.
>
> >>> +++ linux-3.12-my/sound/pci/oxygen/xonar_dg.h
> >>
> >> This file was intended as the interface between xonar_dg.c and the
> >> generic oxygen.c driver.
> >>
> >> That you have to add so much stuff indicates that xonar_dg.c and
> >> xonar_dg_mixer.c are not very independent and maybe should have
> >> stayed a single file.
> >
> > But moving mixer to another file so simplifies things...
>
> Your choice. But it makes it hard to review changes when you move the
> code around in the same patch.
>
>
> Regards,
> Clemens
>
Okay, I won't argue. If the driver will work with the changes, I
don't care. How should I name the subject? Should I mark this with
"RESEND" or "UPDATE" or leave the subject named like "[PATCH 2/2]
snd-oxygen: Fixes for the Xonar DG card"?
--
Kind regards,
Roman Volkov,
v1ron at mail.ru
More information about the Alsa-devel
mailing list