From: Clemens Ladisch <clemens@ladisch.de>
To: Laurence Darby <ldarby@tuffmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] ALSA: oxygen: Fix S/PDIF muting
Date: Tue, 30 Jun 2015 11:43:52 +0200 [thread overview]
Message-ID: <559264D8.9030804@ladisch.de> (raw)
In-Reply-To: <20150629210159.b8c7f6baa83eef02555686f1@tuffmail.com>
Laurence Darby wrote:
> On Sun, 28 Jun 2015 20:44:26 +0200 Clemens Ladisch wrote:
>> Laurence Darby wrote:
>>> The S/PDIF output was muted whenever audio wasn't playing which
>>> resulted in a clicking noise from the DAC when resuming
>>
>> It indeed appears that there are too many oxygen_clear_bits32() calls.
>> However, I don't trust the hardware; please confirm that the S/PDIF
>> output, without an active stream, play zeros and not the last sample.
>
> Well, to test that I created a wav file of about a quarter of a sine
> wave (at about -15dB), consisting of 5520 samples, so it matched the
> alsa buffer size, otherwise aplay pads the buffer with silence.
>
> The chip does continue playing the last sample value, then the speakers
> pop later when something else is played. Is this really an issue
> though? I just found my intel hda chip behaves the same way, and that
> chip's driver leaves it un-muted.
The current problem is that the output gets disabled, then later, when
the driver is about to start the new stream, it enables the output again
(which outputs the last old sample), and then the new stream starts
(usually with zero samples). Going from disabled(=zero) to old-sample
to new-sample(=zero) is an extra pop.
In any case, putting a DC offset on the speakers is a bad idea.
> If this is still going to prevent fixing the popping noise for the
> oxygen chip, what about writing a single 0x00 sample to it in the
> driver instead of muting it?
This is likely to work (but the zero sample has to go through DMA).
At the moment, oxygen_hw_free() pokes at the OXYGEN_DMA_FLUSH register.
Please check if there is an improvement if it also pokes at the
OXYGEN_DMA_RESET register.
>>> Also, the mixer control wasn't actually controlling the S/PDIF
>>> output.
>>
>> Because that is not its purpose to begin with. >:-)
>>
>> The mixer control enables copying the "Multichannel" device to the
>> S/PDIF output. The "Digital" device has no mute, and takes precedence
>> over the multichannel device when both are active.
>
> All my other sound cards (hda, cmedia & emu10k) have an S/PDIF mixer
> control that mutes the output (i.e. causes the DAC to lose the signal),
> in the same way as disabling OXYGEN_SPDIF_OUT_ENABLE does, so I would
> say that it does have mute, and I thought it should be controlled by
> the variable called "spdif_playback_enable"...
I don't remember what the reason for the behaviour of the current
controls was; I probably copied them from some other driver.
> Would an acceptable fix be to create another mixer control for muting
> (and also rename the existing S/PDIF to e.g. "S/PDIF Multichannel"
> so its clearer what that's for)?
AFAICS the usual name would be "PCM".
When making separate changes, please send separate patches.
Regards,
Clemens
next prev parent reply other threads:[~2015-06-30 9:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-28 12:13 [PATCH] ALSA: oxygen: Fix S/PDIF muting Laurence Darby
2015-06-28 18:44 ` Clemens Ladisch
2015-06-29 20:01 ` Laurence Darby
2015-06-30 9:43 ` Clemens Ladisch [this message]
2015-07-05 18:56 ` Laurence Darby
2015-07-05 19:23 ` Clemens Ladisch
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=559264D8.9030804@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=ldarby@tuffmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.