alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: "Heasley, Seth" <seth.heasley@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"perex@perex.cz" <perex@perex.cz>,
	"Ralston, James D" <james.d.ralston@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH 1/6] hda_intel: Add Lynx Point HD Audio Controller DeviceIDs
Date: Tue, 07 Feb 2012 05:51:02 +0100	[thread overview]
Message-ID: <4F30ADB6.1000109@canonical.com> (raw)
In-Reply-To: <DEC3922D1904474A8862C7BFF516EA9A37FB3863@ORSMSX101.amr.corp.intel.com>

On 02/07/2012 01:13 AM, Heasley, Seth wrote:
>>>> This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.
>>>
>>> Thanks. As we asked for oak trail: can you confirm you prefer DMA
>>> Position buffers for detecting current playback/recording position,
>> over
>>> using the LPIB register?
>>
>> Yes, thanks for the notice.
>>
>> I guess this won't need it since it's the successor of PPT.
>> But it's always good to check it for the new hardware, indeed.
>
> I'm also in favor of not rocking the boat, but I'm curious what changing this would entail, and what would be the advantage or rationale for making the change?

Reading the LPIB register, and reading the DMA position buffer, are two 
different methods of reading the current playback (or recording) 
position, i e which sample is currently being played back.

The problem is that some chipsets prefer one method over the other, i e, 
only one of the methods work reliably. And if the other method only 
breaks occasionally, this can be quite difficult to detect and track 
down - we will have users complaining about their audio sometimes either 
sounding distorted, maybe not working at all, or just once in a while 
glitches. All of these symptoms can have many causes, so deducing that 
to a broken playback position is time consuming. That's why I think it's 
worth the extra question, to get it right from the start.

So...thanks in advance for looking it up for us? :-)

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

  reply	other threads:[~2012-02-07  4:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-24  0:24 [PATCH 1/6] hda_intel: Add Lynx Point HD Audio Controller DeviceIDs Seth Heasley
2012-01-24  9:45 ` David Henningsson
2012-01-24  9:54   ` Takashi Iwai
2012-02-07  0:13     ` [alsa-devel] " Heasley, Seth
2012-02-07  4:51       ` David Henningsson [this message]
2012-02-08  0:35         ` Heasley, Seth
2012-02-08  8:30           ` Takashi Iwai

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=4F30ADB6.1000109@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=james.d.ralston@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=seth.heasley@intel.com \
    --cc=tiwai@suse.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).