From: Roman Volkov <v1ron@mail.ru> (by way of Roman Volkov <v1ron@mail.ru>)
To: Clemens Ladisch <clemens@ladisch.de>
Subject: Re: [PATCH 2/2] snd-oxygen: Fixes for the Xonar DG card
Date: Wed, 20 Nov 2013 17:15:23 +0400 [thread overview]
Message-ID: <20131120171523.20772639@v1ron-desktop> (raw)
In-Reply-To: <528CAB1E.7030303@ladisch.de>
В Wed, 20 Nov 2013 13:29:18 +0100
Clemens Ladisch <clemens@ladisch.de> пишет:
> Roman Volkov wrote:
> > Clemens Ladisch <clemens@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@mail.ru
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
prev parent reply other threads:[~2013-11-20 14:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 14:31 [PATCH 2/2] snd-oxygen: Fixes for the Xonar DG card Roman Volkov
2013-11-19 22:23 ` Clemens Ladisch
2013-11-20 10:12 ` Roman Volkov
[not found] ` <528CAB1E.7030303@ladisch.de>
2013-11-20 13:15 ` Roman Volkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131120171523.20772639@v1ron-desktop \
--to=v1ron@mail.ru \
--cc=clemens@ladisch.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).