DragonFlyBSD

:Playing sound using pcm(4)/snd(4) gives bad quality: hiss and hops, like sound isn't playing for very short time periods.
:
:This is experienced:
: - not having SMP in kernel config (eg GENERIC)
: - from dfly-1.5 26th December '05 (24th is ok using kernels from chlamydia);
:including HEAD.
:
:dfly-1.4 is ok, including 1.4.4.
:
:Using audio/mpg123 for MP3, 'cp test.raw /dev/dspW' or pcmplay for decoded sound.
:Buffering audio data with mpg123 -b doesn't sound like making any difference.
:
:CPU load doesn't sound like making any difference.
:Problem experienced on several systems, using snd_via8233 and snd_ich.
:
:No X11 used.
:
: -thomas

Hmm.  That's quite odd.  There aren't any significant source code changes
    bewteen the 24th and 26th of December (I diff'd the 23rd and 27th to be
    conservative).

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Sun, 6 Aug 2006 22:34:10 -0700 (PDT)
Matthew Dillon <dillon@apollo.backplane.com> wrote:

:Playing sound using pcm(4)/snd(4) gives bad quality: hiss and hops, like sound isn't playing for very short time periods.
:
:This is experienced:
: - not having SMP in kernel config (eg GENERIC)
: - from dfly-1.5 26th December '05 (24th is ok using kernels from chlamydia);
:including HEAD.
:
:dfly-1.4 is ok, including 1.4.4.
:
:Using audio/mpg123 for MP3, 'cp test.raw /dev/dspW' or pcmplay for decoded sound.
:Buffering audio data with mpg123 -b doesn't sound like making any difference.
:
:CPU load doesn't sound like making any difference.
:Problem experienced on several systems, using snd_via8233 and snd_ich.
:
:No X11 used.
:
: -thomas

Hmm. That's quite odd. There aren't any significant source code changes
bewteen the 24th and 26th of December (I diff'd the 23rd and 27th to be
conservative).

Equally odd is that I have been using sound regularly on -PREVIEW
throughout the 1.3, 1.5 and now into the 1.7 stages with no problems using
snd_via8233. Perhaps the problem is not in the sound code but interference
from elsewhere. One thought that comes to mind is to check that DMA hasn't
got turned off on the discs.

Problem is a scratz every 10 seconds;
this was easier to hear with 440Hz sinus vs music.

:
:This is experienced:
: - not having SMP in kernel config (eg GENERIC)

Ie. no problem when using SMP;
but problem is still heard having SMP without APIC_IO.

: - from dfly-1.5 26th December '05 (24th is ok using
kernels from chlamydia);
:including HEAD.
:
:dfly-1.4 is ok, including 1.4.4.
:
:Using audio/mpg123 for MP3, 'cp test.raw /dev/dspW' or
pcmplay for decoded sound.
:Buffering audio data with mpg123 -b doesn't sound like
making any difference.
:
:CPU load doesn't sound like making any difference.
:Problem experienced on several systems, using snd_via8233
and snd_ich.

I was wrong; only one pc experienced problem.
(other systems has bad speakers)

:
:No X11 used.
:
: -thomas

Hmm. That's quite odd. There aren't any significant
source code changes
bewteen the 24th and 26th of December (I diff'd the 23rd
and 27th to be
conservative).

-Matt
Matthew Dillon
<dillon@backplane.com>

It turns out problem is irq sharing: pcm0/re0 (too any NICs in test box).

no problem without ip-addr configured.

Btw: sharing irq pcm0/ath0 (on Thinkpad X32) problem isn't heard.

Is irq sharing supported?

-thomas

On 8/13/06, Thomas Nikolajsen <thomas.nikolajsen@mail.dk> wrote:

Matthew Dillon <dillon@apollo.backplane.com> wrote:

:Playing sound using pcm(4)/snd(4) gives bad quality: hiss
and hops, like sound isn't playing for very short time
periods.

Problem is a scratz every 10 seconds;
this was easier to hear with 440Hz sinus vs music.

:
:This is experienced:
: - not having SMP in kernel config (eg GENERIC)

Ie. no problem when using SMP;
but problem is still heard having SMP without APIC_IO.

: - from dfly-1.5 26th December '05 (24th is ok using
kernels from chlamydia);
:including HEAD.
:
:dfly-1.4 is ok, including 1.4.4.
:
:Using audio/mpg123 for MP3, 'cp test.raw /dev/dspW' or
pcmplay for decoded sound.
:Buffering audio data with mpg123 -b doesn't sound like
making any difference.
:
:CPU load doesn't sound like making any difference.
:Problem experienced on several systems, using snd_via8233
and snd_ich.

I was wrong; only one pc experienced problem.
(other systems has bad speakers)

:
:No X11 used.
:
: -thomas

Hmm. That's quite odd. There aren't any significant
source code changes
bewteen the 24th and 26th of December (I diff'd the 23rd
and 27th to be
conservative).

-Matt
Matthew Dillon
<dillon@backplane.com>

It turns out problem is irq sharing: pcm0/re0 (too any NICs in test box).

From 26th December '05: when ip-addr is configured on re0 problem is there;
no problem without ip-addr configured.

Try:
sysctl kern.polling.enable=1
ifconfig re0 polling

See whether the problem still exists

Best Regards,
sephe

Sepherosa Ziehau <sepherosa@gmail.com> wrote:

Try:
sysctl kern.polling.enable=1
ifconfig re0 polling

See whether the problem still exists

Best Regards,
sephe

--
Live Free or Die

It turns out that problem is only experienced with 'no carrier' for re0;
regardless of whether polling(4) is enabled.

-thomas

On 8/14/06, Thomas Nikolajsen <thomas.nikolajsen@mail.dk> wrote:

Sepherosa Ziehau <sepherosa@gmail.com> wrote:

Try:
sysctl kern.polling.enable=1
ifconfig re0 polling

See whether the problem still exists

Best Regards,
sephe

--
Live Free or Die

It turns out that problem is only experienced with 'no carrier' for re0;
regardless of whether polling(4) is enabled.

mmm, then it may be caused by reading the GMII register while there is
no carrier (but it is quite strange why this does not happen on 1.4
branch).
Try following test:
After you have brought re0 up (e.g. by configuring its ip address),
run `ifconfig re0 down` and unplug the cable, see whether the problem
still exists.

BTW, please post the output of `dmesg`

Best Regards,
sephe

Well, it does happen in 1.4 branch: after 1.4_RC1;
in earlier tests I just didn't configure re0; booted 1.4 from CD.

It doesn't.

http://e.wheel.dk/~thomas/dfly/dmesg.GENERIC.gonzales.txt

Best Regards,
sephe

--
Live Free or Die

-thomas

On 8/17/06, Thomas Nikolajsen <thomas.nikolajsen@mail.dk> wrote:

Well, it does happen in 1.4 branch: after 1.4_RC1;
in earlier tests I just didn't configure re0; booted 1.4 from CD.

Then the problem is clearly caused by the rgephy

Please test the HEAD, I have just committed a fix, don't know whether
it works for you or not

Best Regards,
sephe

Problem is still there.

Best Regards,
sephe

--
Live Free or Die

-thomas

On 8/20/06, Thomas Nikolajsen <thomas.nikolajsen@mail.dk> wrote:

Sepherosa Ziehau <sepherosa@gmail.com> wrote:

On 8/17/06, Thomas Nikolajsen <thomas.nikolajsen@mail.dk>
wrote:

Well, it does happen in 1.4 branch: after 1.4_RC1;
in earlier tests I just didn't configure re0; booted 1.4 from CD.

Then the problem is clearly caused by the rgephy

Please test the HEAD, I have just committed a fix, don't
know whether it works for you or not

Problem is still there.

Please try this patch:
http://leaf.dragonflybsd.org/~sephe/rgephy.diff

Best Regards,
sephe

Problem is still there.

Thanks for your effort.
Problem is a minor one for me (now that I have work around).

Btw: I also tested on NetBSD-amd64 (already installed on pc),
3.0 and 3.0.1: issue not there.

Best Regards,
sephe

--
Live Free or Die

is this still present?

admin <bugs@lists.dragonflybsd.org> wrote:
..

is this still present?

..
Yes it is.

-thomas

That's sephes area, so adding him to the list. Maybe somebody will find the issue.

Anyone has seen this happening recently?

Cheers,
Alex Hornung