alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
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

      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).