subject:"\[RFT\] Major snd

2012/1/21 Alexander Motin m...@freebsd.org


 From that description I can conclude that you are passing through
 compressed DTS-HD and TrueHD streams to the receiver. What are the bitrates
 of streams you are playing? It looks like your receiver doesn't receives
 all data. If I understand right, to transfer with compressed bitrates above
 6.144Mbps special High Bit Rate mode should be activated in CODEC, when
 data stream occupies all 8 HDMI channels instead of 2. I haven't
 implemented this feature yet as my receiver doesn't support such HD formats.


i dont think bitrate is over 6.144Mbps.
for TrueHD files, mediainfo reports:

Format profile   : TrueHD / Core
Mode extension   : CM (complete main)
Codec ID : 131
Bit rate mode: Variable / Constant
Bit rate : Unknown / 640 Kbps
Maximum bit rate : 2 868 Kbps / 640 Kbps
Channel(s)   : 6 channels

and for DTS-HDMA, mediainfo can't calculate it, but from description, all
tested file have bitrate below 3689 kbps



 I'll try to make a patch for it a bit later and send you to try.


i'll be happy to try it.

Until that time, is it possible to make your xbmc to decode those HD
 streams into different number of uncompressed LPCM channels to play it that
 way?


yes, it's just an option.

It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM configurations
 with your receiver. Or at least normal definition 7.1 playback would be
 interesting to test (you can just set vchanformat to s16le:7.1 or s32le:7.1
 and play anything).

 i sucessfully tried 6.1 and 7.1 LPCM in 16 bits.
just a small channel order issue (center and a surround back inversion)
which can be solved easily.
i'll add 32bits support in XBMC later for my test but from what you say,
it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s.



 What do you mean that you can't set more then 2 channels? I've never tried
 to set ac3 format with more then 2 channels, but s16le:7.1 and s32le:7.1
 should work fine. At least s16le:5.1 and s32le:5.1 are working perfectly
 for me. For HDA 24bit samples stored in memory as 32bit, so setting s24le
 format only cause extra 24-32bit conversion.


  i never show things like PCMDIR_...: Stream setup in my messages, so
 may be i use oss wrongly.


 They are printed only when hw.snd.verbose set to 4.

 ok thanks for the tips.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 01/24/12 14:57, Mickaël Maillot wrote:

2012/1/21 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
 From that description I can conclude that you are passing through
compressed DTS-HD and TrueHD streams to the receiver. What are the
bitrates of streams you are playing? It looks like your receiver
doesn't receives all data. If I understand right, to transfer with
compressed bitrates above 6.144Mbps special High Bit Rate mode
should be activated in CODEC, when data stream occupies all 8 HDMI
channels instead of 2. I haven't implemented this feature yet as my
receiver doesn't support such HD formats.


i dont think bitrate is over 6.144Mbps.
for TrueHD files, mediainfo reports:

Format profile   : TrueHD / Core
Mode extension   : CM (complete main)
Codec ID : 131
Bit rate mode: Variable / Constant
Bit rate : Unknown / 640 Kbps
Maximum bit rate : 2 868 Kbps / 640 Kbps
Channel(s)   : 6 channels

and for DTS-HDMA, mediainfo can't calculate it, but from description,
all tested file have bitrate below 3689 kbps


Then make sure that your player properly sets sampling rate for the 
playback. Data transferred as 16bit stereo, but depending on bit rate 
may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps 
and 6Mbps respectively). For higher bit rates stream transferred as 
8-channel (High Bit Rate mode) with same set of frequencies (but now up 
to 12, 24 and 49Mbps).



I'll try to make a patch for it a bit later and send you to try.

i'll be happy to try it.

Until that time, is it possible to make your xbmc to decode those HD
streams into different number of uncompressed LPCM channels to play
it that way?


yes, it's just an option.

It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM
configurations with your receiver. Or at least normal definition 7.1
playback would be interesting to test (you can just set vchanformat
to s16le:7.1 or s32le:7.1 and play anything).

i sucessfully tried 6.1 and 7.1 LPCM in 16 bits.
just a small channel order issue (center and a surround back inversion)
which can be solved easily.


In what number of channels which channels are swapped specifically? I've 
compared mapping I am setting in driver with data I have and found no 
problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left, 
Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've 
never could check what mplayer thinks about it because I have no such 
such media. Can you give me some example?



i'll add 32bits support in XBMC later for my test but from what you say,
it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s.


6Mbps limitation is only for data, as they use only two channels by 
default. Audio stream has no such limit.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 01/24/12 15:32, Alexander Motin wrote:

On 01/24/12 14:57, Mickaël Maillot wrote:

2012/1/21 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
From that description I can conclude that you are passing through
compressed DTS-HD and TrueHD streams to the receiver. What are the
bitrates of streams you are playing? It looks like your receiver
doesn't receives all data. If I understand right, to transfer with
compressed bitrates above 6.144Mbps special High Bit Rate mode
should be activated in CODEC, when data stream occupies all 8 HDMI
channels instead of 2. I haven't implemented this feature yet as my
receiver doesn't support such HD formats.


i dont think bitrate is over 6.144Mbps.
for TrueHD files, mediainfo reports:

Format profile : TrueHD / Core
Mode extension : CM (complete main)
Codec ID : 131
Bit rate mode : Variable / Constant
Bit rate : Unknown / 640 Kbps
Maximum bit rate : 2 868 Kbps / 640 Kbps
Channel(s) : 6 channels

and for DTS-HDMA, mediainfo can't calculate it, but from description,
all tested file have bitrate below 3689 kbps


Then make sure that your player properly sets sampling rate for the
playback. Data transferred as 16bit stereo, but depending on bit rate
may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps
and 6Mbps respectively). For higher bit rates stream transferred as
8-channel (High Bit Rate mode) with same set of frequencies (but now up
to 12, 24 and 49Mbps).


I'll try to make a patch for it a bit later and send you to try.

i'll be happy to try it.


Here is it: http://people.freebsd.org/~mav/hda.HBR.patch
It should activate HBR mode if you try to play stream with AC3 format 
and 8 channels (6Mbps).



Until that time, is it possible to make your xbmc to decode those HD
streams into different number of uncompressed LPCM channels to play
it that way?


yes, it's just an option.

It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM
configurations with your receiver. Or at least normal definition 7.1
playback would be interesting to test (you can just set vchanformat
to s16le:7.1 or s32le:7.1 and play anything).

i sucessfully tried 6.1 and 7.1 LPCM in 16 bits.
just a small channel order issue (center and a surround back inversion)
which can be solved easily.


In what number of channels which channels are swapped specifically? I've
compared mapping I am setting in driver with data I have and found no
problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left,
Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've
never could check what mplayer thinks about it because I have no such
such media. Can you give me some example?


i'll add 32bits support in XBMC later for my test but from what you say,
it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s.


6Mbps limitation is only for data, as they use only two channels by
default. Audio stream has no such limit.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012/1/24 Alexander Motin m...@freebsd.org

On 01/24/12 15:32, Alexander Motin wrote:

On 01/24/12 14:57, Mickaël Maillot wrote:

2012/1/21 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
From that description I can conclude that you are passing through
compressed DTS-HD and TrueHD streams to the receiver. What are the
bitrates of streams you are playing? It looks like your receiver
doesn't receives all data. If I understand right, to transfer with
compressed bitrates above 6.144Mbps special High Bit Rate mode
should be activated in CODEC, when data stream occupies all 8 HDMI
channels instead of 2. I haven't implemented this feature yet as my
receiver doesn't support such HD formats.

i dont think bitrate is over 6.144Mbps.
for TrueHD files, mediainfo reports:

Format profile : TrueHD / Core
Mode extension : CM (complete main)
Codec ID : 131
Bit rate mode : Variable / Constant
Bit rate : Unknown / 640 Kbps
Maximum bit rate : 2 868 Kbps / 640 Kbps
Channel(s) : 6 channels

and for DTS-HDMA, mediainfo can't calculate it, but from description,
all tested file have bitrate below 3689 kbps

Then make sure that your player properly sets sampling rate for the
playback. Data transferred as 16bit stereo, but depending on bit rate
may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps
and 6Mbps respectively). For higher bit rates stream transferred as
8-channel (High Bit Rate mode) with same set of frequencies (but now up
to 12, 24 and 49Mbps).

I'll try to make a patch for it a bit later and send you to try.

i'll be happy to try it.

Here is it:
http://people.freebsd.org/~**mav/hda.HBR.patchhttp://people.freebsd.org/~mav/hda.HBR.patch
It should activate HBR mode if you try to play stream with AC3 format and
8 channels (6Mbps).

no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3,
SNDCTL_DSP_CHANNELS always return 2 channels even if i set SNDCTL_DSP_SPEED
to 192000.
and i think it's why if ((ch-fmt AFMT_AC3) (cchn == 8)) can't be
true.
i checked my /v/l/messages and saw PCMDIR_PLAY chan_count=0x01.

i can set 8 channels without problems with AFMT_S32_LE format and sound
works:
kernel: hdac1: 36864Kbps of 92160Kbps bandwidth used
kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02801000 (7.1) speed=192000
kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: fmt=0x1837, dfmt=0x0001,
chan=0x0010, chan_count=0x07, stripe=1

Until that time, is it possible to make your xbmc to decode those HD
streams into different number of uncompressed LPCM channels to play
it that way?

yes, it's just an option.

It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM
configurations with your receiver. Or at least normal definition 7.1
playback would be interesting to test (you can just set vchanformat
to s16le:7.1 or s32le:7.1 and play anything).

i sucessfully tried 6.1 and 7.1 LPCM in 16 bits.
just a small channel order issue (center and a surround back inversion)
which can be solved easily.

In what number of channels which channels are swapped specifically? I've
compared mapping I am setting in driver with data I have and found no
problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left,
Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've
never could check what mplayer thinks about it because I have no such
such media. Can you give me some example?

ok mapping is good, i think the swap is in XBMC, i'll check later with
xbmc's audio dev.

i'll add 32bits support in XBMC later for my test but from what you say,
it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s.

6Mbps limitation is only for data, as they use only two channels by
default. Audio stream has no such limit.

yep, it works !
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 01/25/12 00:13, Mickaël Maillot wrote:

2012/1/24 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
Here is it: http://people.freebsd.org/~__mav/hda.HBR.patch
http://people.freebsd.org/~mav/hda.HBR.patch
It should activate HBR mode if you try to play stream with AC3
format and 8 channels (6Mbps).

no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3,
SNDCTL_DSP_CHANNELS always return 2 channels even if i
set SNDCTL_DSP_SPEED to 192000.
and i think it's why if ((ch-fmt  AFMT_AC3)  (cchn == 8)) can't be
true.
i checked my /v/l/messages and saw PCMDIR_PLAY chan_count=0x01.


Number of channels should be set to 8 by application when it expects bit 
rate above 6Mbps. Sample rate, as I've described, just give more fine 
control. Increasing sample rate does not automatically increase 
channels. They are orthogonal:

 Rate   48  96  192 48  96  192
 Channels   2   2   2   8   8   8
 --
 Mbps   1.5 3   6   12  24  49

What I've forgot is to allow 8ch format. :) Add the patch below. Hope 
sound(4) has no other limitations for it.


--- hdaa.c  (revision 230511)
+++ hdaa.c  (working copy)
@@ -4979,6 +4979,8 @@
}
if (HDA_PARAM_SUPP_STREAM_FORMATS_AC3(fmtcap)) {
ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0);
+   if (channels = 8)
+   ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 
8, 0);

}
ch-fmtlist[i] = 0;
i = 0;

But in your case I think it should be enough to just increase sample 
rate to 96 or 192KHz.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 01/25/12 00:33, Alexander Motin wrote:

On 01/25/12 00:13, Mickaël Maillot wrote:

2012/1/24 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
Here is it: http://people.freebsd.org/~__mav/hda.HBR.patch
http://people.freebsd.org/~mav/hda.HBR.patch
It should activate HBR mode if you try to play stream with AC3
format and 8 channels (6Mbps).

no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3,
SNDCTL_DSP_CHANNELS always return 2 channels even if i
set SNDCTL_DSP_SPEED to 192000.
and i think it's why if ((ch-fmt  AFMT_AC3)  (cchn == 8)) can't be
true.
i checked my /v/l/messages and saw PCMDIR_PLAY chan_count=0x01.


Number of channels should be set to 8 by application when it expects bit
rate above 6Mbps. Sample rate, as I've described, just give more fine
control. Increasing sample rate does not automatically increase
channels. They are orthogonal:
Rate 48 96 192 48 96 192
Channels 2 2 2 8 8 8
--
Mbps 1.5 3 6 12 24 49

What I've forgot is to allow 8ch format. :) Add the patch below. Hope
sound(4) has no other limitations for it.


Hmm. Looks like there is some limitation. You may grep kernel for 
AFMT_PASSTHROUGH and find two XXX force ... comments and code, 
including forcing 2 channels for AC3. Luckily for not part for frequency 
is commented out. Further we may try to comment or modify part about 
number of channels.



--- hdaa.c (revision 230511)
+++ hdaa.c (working copy)
@@ -4979,6 +4979,8 @@
}
if (HDA_PARAM_SUPP_STREAM_FORMATS_AC3(fmtcap)) {
ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0);
+ if (channels = 8)
+ ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0);
}
ch-fmtlist[i] = 0;
i = 0;

But in your case I think it should be enough to just increase sample
rate to 96 or 192KHz.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012/1/24 Alexander Motin m...@freebsd.org

 On 01/25/12 00:33, Alexander Motin wrote:

 On 01/25/12 00:13, Mickaël Maillot wrote:

 2012/1/24 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
 Here is it: 
 http://people.freebsd.org/~__**mav/hda.HBR.patchhttp://people.freebsd.org/~__mav/hda.HBR.patch
 http://people.freebsd.org/~**mav/hda.HBR.patchhttp://people.freebsd.org/~mav/hda.HBR.patch
 
 It should activate HBR mode if you try to play stream with AC3
 format and 8 channels (6Mbps).

 no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3,
 SNDCTL_DSP_CHANNELS always return 2 channels even if i
 set SNDCTL_DSP_SPEED to 192000.
 and i think it's why if ((ch-fmt  AFMT_AC3)  (cchn == 8)) can't be
 true.
 i checked my /v/l/messages and saw PCMDIR_PLAY chan_count=0x01.


 Number of channels should be set to 8 by application when it expects bit
 rate above 6Mbps. Sample rate, as I've described, just give more fine
 control. Increasing sample rate does not automatically increase
 channels. They are orthogonal:
 Rate 48 96 192 48 96 192
 Channels 2 2 2 8 8 8
 --**
 Mbps 1.5 3 6 12 24 49


ok so set 8 channels is just to allow more bandwidth.
i just looked at alsa hdmi code (because i never find oss code that can
play hd audio),
they set 192k and 8 channels for every DTS HD / TRUEHD / E-AC3 file, so i
was thinking to do the same.


 What I've forgot is to allow 8ch format. :) Add the patch below. Hope
 sound(4) has no other limitations for it.


 Hmm. Looks like there is some limitation. You may grep kernel for
 AFMT_PASSTHROUGH and find two XXX force ... comments and code, including
 forcing 2 channels for AC3. Luckily for not part for frequency is commented
 out. Further we may try to comment or modify part about number of channels.


spotted and commented



  --- hdaa.c (revision 230511)
 +++ hdaa.c (working copy)
 @@ -4979,6 +4979,8 @@
 }
 if (HDA_PARAM_SUPP_STREAM_**FORMATS_AC3(fmtcap)) {
 ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0);
 + if (channels = 8)
 + ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0);
 }
 ch-fmtlist[i] = 0;
 i = 0;

 But in your case I think it should be enough to just increase sample
 rate to 96 or 192KHz.



so if my problem persist after settings 8 channels, i'll blame xbmc oss
part.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 25.01.2012 01:32, Mickaël Maillot wrote:

2012/1/24 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
Number of channels should be set to 8 by application when it
expects bit
rate above 6Mbps. Sample rate, as I've described, just give more
fine
control. Increasing sample rate does not automatically increase
channels. They are orthogonal:
Rate 48 96 192 48 96 192
Channels 2 2 2 8 8 8
--__
Mbps 1.5 3 6 12 24 49


ok so set 8 channels is just to allow more bandwidth.
i just looked at alsa hdmi code (because i never find oss code that can
play hd audio),
they set 192k and 8 channels for every DTS HD / TRUEHD / E-AC3 file, so
i was thinking to do the same.


HBR mode (8 channels) is not always supported by hardware and not 
defined by HDMI 1.1 spec (not sure about 1.2). So I think if possible, 
it would be nice to differentiate them.



What I've forgot is to allow 8ch format. :) Add the patch below.
Hope
sound(4) has no other limitations for it.

Hmm. Looks like there is some limitation. You may grep kernel for
AFMT_PASSTHROUGH and find two XXX force ... comments and code,
including forcing 2 channels for AC3. Luckily for not part for
frequency is commented out. Further we may try to comment or modify
part about number of channels.

spotted and commented

--- hdaa.c (revision 230511)
+++ hdaa.c (working copy)
@@ -4979,6 +4979,8 @@
}
if (HDA_PARAM_SUPP_STREAM___FORMATS_AC3(fmtcap)) {
ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0);
+ if (channels = 8)
+ ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0);
}
ch-fmtlist[i] = 0;
i = 0;

But in your case I think it should be enough to just increase sample
rate to 96 or 192KHz.

so if my problem persist after settings 8 channels, i'll blame xbmc oss
part.


Can't wait to know result. :)

--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-24 Thread Zhihao Yuan

On Tue, Jan 24, 2012 at 5:39 PM, Alexander Motin m...@freebsd.org wrote:
 On 25.01.2012 01:32, Mickaël Maillot wrote:

 2012/1/24 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org
        Number of channels should be set to 8 by application when it
        expects bit
        rate above 6Mbps. Sample rate, as I've described, just give more
        fine
        control. Increasing sample rate does not automatically increase
        channels. They are orthogonal:
        Rate 48 96 192 48 96 192
        Channels 2 2 2 8 8 8
        --__

        Mbps 1.5 3 6 12 24 49


 ok so set 8 channels is just to allow more bandwidth.
 i just looked at alsa hdmi code (because i never find oss code that can
 play hd audio),
 they set 192k and 8 channels for every DTS HD / TRUEHD / E-AC3 file, so
 i was thinking to do the same.


 HBR mode (8 channels) is not always supported by hardware and not defined by
 HDMI 1.1 spec (not sure about 1.2). So I think if possible, it would be nice
 to differentiate them.

        What I've forgot is to allow 8ch format. :) Add the patch below.
        Hope
        sound(4) has no other limitations for it.

    Hmm. Looks like there is some limitation. You may grep kernel for
    AFMT_PASSTHROUGH and find two XXX force ... comments and code,
    including forcing 2 channels for AC3. Luckily for not part for
    frequency is commented out. Further we may try to comment or modify
    part about number of channels.

 spotted and commented

        --- hdaa.c (revision 230511)
        +++ hdaa.c (working copy)
        @@ -4979,6 +4979,8 @@
        }
        if (HDA_PARAM_SUPP_STREAM___FORMATS_AC3(fmtcap)) {

        ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0);
        + if (channels = 8)
        + ch-fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0);
        }
        ch-fmtlist[i] = 0;
        i = 0;

        But in your case I think it should be enough to just increase
 sample
        rate to 96 or 192KHz.

 so if my problem persist after settings 8 channels, i'll blame xbmc oss
 part.


 Can't wait to know result. :)

 --
 Alexander Motin

 ___
 freebsd-multime...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
 To unsubscribe, send any mail to
 freebsd-multimedia-unsubscr...@freebsd.org

Oops, device_delete_children is not available on 8_RELENG.

-- 
Zhihao Yuan, nickname lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012/1/25 Alexander Motin m...@freebsd.org


 What I've forgot is to allow 8ch format. :) Add the patch below.
Hope
sound(4) has no other limitations for it.

Hmm. Looks like there is some limitation. You may grep kernel for
AFMT_PASSTHROUGH and find two XXX force ... comments and code,
including forcing 2 channels for AC3. Luckily for not part for
frequency is commented out. Further we may try to comment or modify
part about number of channels.

 spotted and commented

 so if my problem persist after settings 8 channels, i'll blame xbmc oss
 part.


 Can't wait to know result. :)

 --
 Alexander Motin



ok so unfortunately it's does not work :(
first: with vchan disable, i cant set format to AFMT_AC3, ioctl always
return -1
in /v/l/messages:
Jan 25 08:09:18 htpc kernel: pcm4: chn_setformat(): Format change
0x00100400 failed, falling back to 0x0018
so may be my change in sys/dev/sound/pcm/channel.c is not good ? i just
commented:
/* XXX force stereo */
if (format  AFMT_PASSTHROUGH)
format = SND_FORMAT(format, AFMT_PASSTHROUGH_CHANNEL,
AFMT_PASSTHROUGH_EXTCHANNEL);

next with vchan: i can set ac3 to 2 channels and 8 channels.
when i try to play DTS HDMA or TRUEHD, i set ac3, 8 channels, 192k
and no sound ! before i had: dtshdma: some part of sound (like all data
cant be send) and truehd: some crapy bipbip
now everything seems to be ok for the player, procstat -f write counter
grows up, but no sound from my receiver: no channel input, nothing showed,
like nothing is send to him.
no error in xbmc.log or in messages:
Jan 25 08:15:35 htpc kernel: pcm4: chn_start(): VCHAN PARENT starting!
(PCMDIR_PLAY/running) (ready=8192 force=1 i=1 j=0 intrtimeout=2 latency=2ms)
Jan 25 08:15:35 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used
Jan 25 08:15:35 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02800400
(7.1) speed=192000
Jan 25 08:15:35 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4:
fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1
Jan 25 08:15:35 htpc kernel: pcm4: chn_trigger() pcm4:play:dsp4.p0: calling
go=0x0001 , prev=0x
Jan 25 08:15:35 htpc kernel: pcm4: chn_trigger() pcm4:virtual:dsp4.vp0:
calling go=0x0001 , prev=0x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-23 Thread Yuri Pankov

On Wed, Jan 18, 2012 at 06:02:13PM +0200, Alexander Motin wrote:
 On 01/12/12 15:04, Yuri Pankov wrote:
  On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:
  On 01/12/12 14:18, Yuri Pankov wrote:
  On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
  I would like request for testing of my work on further HDA sound driver
  improvement.
  [...]
  Patch can be found here:
  http://people.freebsd.org/~mav/hda.rewrite.patch
 
  Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
  and 8-STABLE branches also.
 
  Patch applied cleanly to r230008 using `svn patch`.
 
  hdacc0:NVidia GT220 HDA CODEC   at cad 0 on hdac0
  hdaa0:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc0
  pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa0
  hdacc1:NVidia GT220 HDA CODEC   at cad 1 on hdac0
  hdaa1:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc1
  pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa1
  hdacc2:NVidia GT220 HDA CODEC   at cad 2 on hdac0
  hdaa2:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc2
  pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa2
  hdacc3:NVidia GT220 HDA CODEC   at cad 3 on hdac0
  hdaa3:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc3
  pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa3
  hdacc4:IDT 92HD75BX HDA CODEC   at cad 0 on hdac1
  hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group   at nid 1 on hdacc4
  pcm4:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 13 and 11 on hdaa4
  pcm5:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 15 and 24 on hdaa4
  pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital)   at nid 30 on hdaa4
 
  pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however
 
  Thank you.
 
  I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
  mplayer just pauses at the beggining, trying to cat anything to
  /dev/dsp{0-3}.0 gives:
 
  pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel 
  dead
 
  It was the same with the old driver and I'm not sure if it's (most
  likely) my misconfiguration or a driver problem.
 
  It sounds more like a driver problem. HDMI audio is still not very well
  discovered area, and, according to ALSA reading, NVidia HDMI is also not
  very standard. Probably I'll finally have to buy something to
  experiment. What card do you have?
 
  It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
  identified by x11/nvidia-driver).
 
 I've reproduced it on NVidia GT210. It seems there is some problem with 
 MSI generation. Switching to legacy PCI interrupts fixes problem for me. 
 Linux HDA driver disables MSI for all NVidia controllers.
 
 Try to add hint.hdac.0.msi=0 into the /boot/loader.conf.

Sorry for delay. Indeed, setting hint.hdac.0.msi=0 helped.


Thanks,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

On 01/21/12 15:17, Mickaël Maillot wrote:

So i tried DTS-HDMA and Dolby TrueHD without success.
when i play DTS-HDMA, my receiver display DTS-HR and seams to play dts
core with lots of interruptions.
and when i play TrueHD, my receiver display TrueHD but doesn't play
anything.

From that description I can conclude that you are passing through
compressed DTS-HD and TrueHD streams to the receiver. What are the
bitrates of streams you are playing? It looks like your receiver doesn't
receives all data. If I understand right, to transfer with compressed
bitrates above 6.144Mbps special High Bit Rate mode should be activated
in CODEC, when data stream occupies all 8 HDMI channels instead of 2. I
haven't implemented this feature yet as my receiver doesn't support such
HD formats.

I'll try to make a patch for it a bit later and send you to try. Until
that time, is it possible to make your xbmc to decode those HD streams
into different number of uncompressed LPCM channels to play it that way?
It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM
configurations with your receiver. Or at least normal definition 7.1
playback would be interesting to test (you can just set vchanformat to
s16le:7.1 or s32le:7.1 and play anything).

and sysctl show:
dev.pcm.4.play.vchanmode: passthrough
dev.pcm.4.play.vchanrate: 192000
dev.pcm.4.play.vchanformat: ac3:2.0

i tried without vchan with same results.

i can't set more than 2 channels for my hdmi output (dsp4), i want to
set 8 channels like alsa does.

What do you mean that you can't set more then 2 channels? I've never
tried to set ac3 format with more then 2 channels, but s16le:7.1 and
s32le:7.1 should work fine. At least s16le:5.1 and s32le:5.1 are working
perfectly for me. For HDA 24bit samples stored in memory as 32bit, so
setting s24le format only cause extra 24-32bit conversion.

i never show things like PCMDIR_...: Stream setup in my messages, so
may be i use oss wrongly.

They are printed only when hw.snd.verbose set to 4.

you can find the source code of xbmc used to play losseless file here:
https://github.com/Fneufneu/xbmc/blob/freebsdAE/xbmc/cores/AudioEngine/Sinks/AESinkOSS.cpp

and my dmesg: http://fneufn.eu/freebsd/dmesg.verb.htpc.20120121.txt

--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

On 01/21/12 16:28, Alexander Motin wrote:

On 01/21/12 15:17, Mickaël Maillot wrote:

I mean play anything uncompressed.

and sysctl show:
dev.pcm.4.play.vchanmode: passthrough
dev.pcm.4.play.vchanrate: 192000
dev.pcm.4.play.vchanformat: ac3:2.0

i tried without vchan with same results.

i can't set more than 2 channels for my hdmi output (dsp4), i want to
set 8 channels like alsa does.

i never show things like PCMDIR_...: Stream setup in my messages, so
may be i use oss wrongly.

They are printed only when hw.snd.verbose set to 4.

you can find the source code of xbmc used to play losseless file here:
https://github.com/Fneufneu/xbmc/blob/freebsdAE/xbmc/cores/AudioEngine/Sinks/AESinkOSS.cpp

and my dmesg: http://fneufn.eu/freebsd/dmesg.verb.htpc.20120121.txt

--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-21 Thread Dominic Fandrey


Hello,

On 11/01/2012 20:33, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound driver 
improvement.
...

Comments and tests results are welcome!


I've been testing the first version of your patch on an HP 6510b, since
the 12th of January.

hdac0@pci0:0:27:0:  class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 
hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) HD Audio Controller'
class  = multimedia
subclass   = HDA


mixer

Mixer vol  is currently set to  80:80
Mixer bass is currently set to  75:75
Mixer treble   is currently set to  40:40
Mixer pcm  is currently set to 100:100
Mixer speaker  is currently set to   0:0
Mixer line is currently set to   0:0
Mixer mic  is currently set to   0:0
Mixer rec  is currently set to  50:50
Mixer igainis currently set to   0:0
Mixer ogainis currently set to   0:0
Mixer monitor  is currently set to   0:0
Recording source: monitor

So far I haven't encountered any regressions. There are however some small
issues that also are present with the old driver.

I have the following selection of recording devices:
Mixer line is currently set to   0:0
Mixer mic  is currently set to   0:0
Mixer monitor  is currently set to   0:0

To record from the microphone, I have to use the monitor device:
Recording source: monitor

Physically neither the notebook nor the docking station have a line
in socket. Of course such a thing might simply be on board and NC.

Setting a volume for line, mic or monitor has no effect. To hear the
microphone on my speakers/headphones I have to use igain instead.
Igain sets the microphone volume independent of the recording source.

There's also ogain, which doesn't seem to do anything either.

What I expect is that the recording source for the microphone was
mic and that the monitor recording source could be used to record
the cumulative output of all channels.

Regards

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 01/21/12 18:24, Dominic Fandrey wrote:

Hello,

On 11/01/2012 20:33, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound
driver improvement.
...

Comments and tests results are welcome!


I've been testing the first version of your patch on an HP 6510b, since
the 12th of January.

hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) HD Audio Controller'
class = multimedia
subclass = HDA


mixer

Mixer vol is currently set to 80:80
Mixer bass is currently set to 75:75
Mixer treble is currently set to 40:40
Mixer pcm is currently set to 100:100
Mixer speaker is currently set to 0:0
Mixer line is currently set to 0:0
Mixer mic is currently set to 0:0
Mixer rec is currently set to 50:50
Mixer igain is currently set to 0:0
Mixer ogain is currently set to 0:0
Mixer monitor is currently set to 0:0
Recording source: monitor

So far I haven't encountered any regressions. There are however some small
issues that also are present with the old driver.

I have the following selection of recording devices:
Mixer line is currently set to 0:0
Mixer mic is currently set to 0:0
Mixer monitor is currently set to 0:0

To record from the microphone, I have to use the monitor device:
Recording source: monitor


monitor is a name used for the second (or built-in) microphone. List of 
names in OSS is quite limited, so I had to choose one and that fit best.



Physically neither the notebook nor the docking station have a line
in socket. Of course such a thing might simply be on board and NC.


It is question to vendor, why it haven't disabled it in codec 
configuration if it is not implemented in hardware. If you like, you can 
do it with device hints.



Setting a volume for line, mic or monitor has no effect. To hear the
microphone on my speakers/headphones I have to use igain instead.


Difficult to say something without knowing model of codec or having 
verbose dmesg output. Depending on codec model, line, mic and monitor 
input may have or not have much controls. There may be just mutters, or 
may be just their volume in input monitoring.



Igain sets the microphone volume independent of the recording source.


As written in man page, igain controls input-to-output monitoring 
loopback level. It is not used for pre-amplification as you may think, 
because there usually more then one input that needs that control.



There's also ogain, which doesn't seem to do anything either.


ogain is used to control EAPD signal, that on some laptops used to 
control external power amplifier. It is impossible for driver to find 
whether this signal is used, so it is exposed always when present.



What I expect is that the recording source for the microphone was
mic and that the monitor recording source could be used to record
the cumulative output of all channels.


About mic, it is only question of terminology. What's about mixed 
recording, depending on codec it may be possible in two ways: either by 
recording from special device called mix, or by choosing several 
recording sources with `mixer =rec mic ; mixer +rec monitor; mixer +rec 
line`.


Just now I am working on complete rewrite of the volumes control in the 
driver. Terminology will remain the same, but number of present controls 
and their functionality/quality should improve.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 01/21/12 18:48, Alexander Motin wrote:

On 01/21/12 18:24, Dominic Fandrey wrote:

On 11/01/2012 20:33, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound
driver improvement.
...

Comments and tests results are welcome!


I've been testing the first version of your patch on an HP 6510b, since
the 12th of January.

hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) HD Audio Controller'
class = multimedia
subclass = HDA


mixer

Mixer vol is currently set to 80:80
Mixer bass is currently set to 75:75
Mixer treble is currently set to 40:40
Mixer pcm is currently set to 100:100
Mixer speaker is currently set to 0:0
Mixer line is currently set to 0:0
Mixer mic is currently set to 0:0
Mixer rec is currently set to 50:50
Mixer igain is currently set to 0:0
Mixer ogain is currently set to 0:0
Mixer monitor is currently set to 0:0
Recording source: monitor

So far I haven't encountered any regressions. There are however some
small
issues that also are present with the old driver.

I have the following selection of recording devices:
Mixer line is currently set to 0:0
Mixer mic is currently set to 0:0
Mixer monitor is currently set to 0:0

To record from the microphone, I have to use the monitor device:
Recording source: monitor


monitor is a name used for the second (or built-in) microphone. List of
names in OSS is quite limited, so I had to choose one and that fit best.


Physically neither the notebook nor the docking station have a line
in socket. Of course such a thing might simply be on board and NC.


It is question to vendor, why it haven't disabled it in codec
configuration if it is not implemented in hardware. If you like, you can
do it with device hints.


Setting a volume for line, mic or monitor has no effect. To hear the
microphone on my speakers/headphones I have to use igain instead.


Difficult to say something without knowing model of codec or having
verbose dmesg output. Depending on codec model, line, mic and monitor
input may have or not have much controls. There may be just mutters, or
may be just their volume in input monitoring.


Igain sets the microphone volume independent of the recording source.


As written in man page, igain controls input-to-output monitoring
loopback level. It is not used for pre-amplification as you may think,
because there usually more then one input that needs that control.


There's also ogain, which doesn't seem to do anything either.


ogain is used to control EAPD signal, that on some laptops used to
control external power amplifier. It is impossible for driver to find
whether this signal is used, so it is exposed always when present.


What I expect is that the recording source for the microphone was
mic and that the monitor recording source could be used to record
the cumulative output of all channels.


About mic, it is only question of terminology. What's about mixed
recording, depending on codec it may be possible in two ways: either by
recording from special device called mix, or by choosing several
recording sources with `mixer =rec mic ; mixer +rec monitor; mixer +rec
line`.


Or it may be just technically impossible.

If record the cumulative output of all channels means you want to 
record from playback, then on most codecs it is technically impossible. 
I've seen only one or two allowing it and it is not supported now.



Just now I am working on complete rewrite of the volumes control in the
driver. Terminology will remain the same, but number of present controls
and their functionality/quality should improve.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-18 Thread Alexander Motin


On 01/12/12 15:04, Yuri Pankov wrote:

On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:

On 01/12/12 14:18, Yuri Pankov wrote:

On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound driver
improvement.

[...]

Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.


Patch applied cleanly to r230008 using `svn patch`.

hdacc0:NVidia GT220 HDA CODEC   at cad 0 on hdac0
hdaa0:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc0
pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa0
hdacc1:NVidia GT220 HDA CODEC   at cad 1 on hdac0
hdaa1:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc1
pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa1
hdacc2:NVidia GT220 HDA CODEC   at cad 2 on hdac0
hdaa2:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc2
pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa2
hdacc3:NVidia GT220 HDA CODEC   at cad 3 on hdac0
hdaa3:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc3
pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa3
hdacc4:IDT 92HD75BX HDA CODEC   at cad 0 on hdac1
hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group   at nid 1 on hdacc4
pcm4:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 13 and 11 on hdaa4
pcm5:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 15 and 24 on hdaa4
pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital)   at nid 30 on hdaa4

pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however


Thank you.


I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:

pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead

It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.


It sounds more like a driver problem. HDMI audio is still not very well
discovered area, and, according to ALSA reading, NVidia HDMI is also not
very standard. Probably I'll finally have to buy something to
experiment. What card do you have?


It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
identified by x11/nvidia-driver).


I've reproduced it on NVidia GT210. It seems there is some problem with 
MSI generation. Switching to legacy PCI interrupts fixes problem for me. 
Linux HDA driver disables MSI for all NVidia controllers.


Try to add hint.hdac.0.msi=0 into the /boot/loader.conf.

--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-18 Thread Alexander Motin


On 01/16/12 13:26, Mickaël Maillot wrote:

it could be realy nice to have nvidia hdmi support first 2 channels and
next 8 channels.
i have an ION2 platform and i'm open to test everything.


I've just committed (http://svn.freebsd.org/changeset/base/230312) to 
head patch (http://people.freebsd.org/~mav/hda.hdmi.patch), 
significantly improving HDMI/DisplayPort audio support. Testers, go! :)


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-18 Thread Mickaël Maillot

2012/1/18 Alexander Motin m...@freebsd.org

 On 01/16/12 13:26, Mickaël Maillot wrote:

 it could be realy nice to have nvidia hdmi support first 2 channels and
 next 8 channels.
 i have an ION2 platform and i'm open to test everything.


 I've just committed 
 (http://svn.freebsd.org/**changeset/base/230312http://svn.freebsd.org/changeset/base/230312)
 to head patch 
 (http://people.freebsd.org/~**mav/hda.hdmi.patchhttp://people.freebsd.org/~mav/hda.hdmi.patch),
 significantly improving HDMI/DisplayPort audio support. Testers, go! :)


Thank a lot !

kernel patched, reboot, and still no sound over hdmi, so i add in my
loader.conf:
hint.hdac.1.msi=0
reboot, and now it works ! so your patch does not disable msi by default
for my chip.
i tried AC3, DTS, DTS ES 6.1, and all works fine like on optical output.
tomorow i'll try 8 channels with DTS HDMA, Dolby TrueHD and LPCM 7.1 (i
need to recompile xbmc with some changes)

you can find verbose dmesg here:
http://fneufn.eu/freebsd/dmesg.verb.htpc.20120118.txt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-18 Thread Alexander Motin


On 01/19/12 00:04, Mickaël Maillot wrote:

2012/1/18 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org

On 01/16/12 13:26, Mickaël Maillot wrote:

it could be realy nice to have nvidia hdmi support first 2
channels and
next 8 channels.
i have an ION2 platform and i'm open to test everything.


I've just committed (http://svn.freebsd.org/__changeset/base/230312
http://svn.freebsd.org/changeset/base/230312) to head patch
(http://people.freebsd.org/~__mav/hda.hdmi.patch
http://people.freebsd.org/~mav/hda.hdmi.patch), significantly
improving HDMI/DisplayPort audio support. Testers, go! :)


Thank a lot !

kernel patched, reboot, and still no sound over hdmi, so i add in my
loader.conf:
hint.hdac.1.msi=0
reboot, and now it works ! so your patch does not disable msi by default
for my chip.
i tried AC3, DTS, DTS ES 6.1, and all works fine like on optical output.
tomorow i'll try 8 channels with DTS HDMA, Dolby TrueHD and LPCM 7.1 (i
need to recompile xbmc with some changes)

you can find verbose dmesg here:
http://fneufn.eu/freebsd/dmesg.verb.htpc.20120118.txt


I don't see there neither controller PCI ID, nor ELD content. Could you 
show also `pciconf -lv` and verbose `dmesg` after Xorg start (if this 
was before)?


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-18 Thread Mickaël Maillot

2012/1/19 Alexander Motin m...@freebsd.org

 On 01/19/12 00:04, Mickaël Maillot wrote:

 2012/1/18 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org


On 01/16/12 13:26, Mickaël Maillot wrote:

it could be realy nice to have nvidia hdmi support first 2
channels and
next 8 channels.
i have an ION2 platform and i'm open to test everything.


I've just committed 
 (http://svn.freebsd.org/__**changeset/base/230312http://svn.freebsd.org/__changeset/base/230312

 http://svn.freebsd.org/**changeset/base/230312http://svn.freebsd.org/changeset/base/230312)
 to head patch

 (http://people.freebsd.org/~__**mav/hda.hdmi.patchhttp://people.freebsd.org/~__mav/hda.hdmi.patch

 http://people.freebsd.org/~**mav/hda.hdmi.patchhttp://people.freebsd.org/~mav/hda.hdmi.patch),
 significantly

improving HDMI/DisplayPort audio support. Testers, go! :)


 Thank a lot !

 kernel patched, reboot, and still no sound over hdmi, so i add in my
 loader.conf:
 hint.hdac.1.msi=0
 reboot, and now it works ! so your patch does not disable msi by default
 for my chip.
 i tried AC3, DTS, DTS ES 6.1, and all works fine like on optical output.
 tomorow i'll try 8 channels with DTS HDMA, Dolby TrueHD and LPCM 7.1 (i
 need to recompile xbmc with some changes)

 you can find verbose dmesg here:
 http://fneufn.eu/freebsd/**dmesg.verb.htpc.20120118.txthttp://fneufn.eu/freebsd/dmesg.verb.htpc.20120118.txt


 I don't see there neither controller PCI ID, nor ELD content. Could you
 show also `pciconf -lv` and verbose `dmesg` after Xorg start (if this was
 before)?


sorry, i was booting on the wrong kernel .
here is the good verbose dmesg with ELD: http://fneufn.eu/freebsd/**
dmesg.verb.htpc.20120119.txthttp://fneufn.eu/freebsd/dmesg.verb.htpc.20120118.txt

pciconf -vl with nvidia part:

vgapci0@pci0:3:0:0: class=0x03 card=0x841f1043 chip=0x0a6410de
rev=0xa2 hdr=0x00
vendor = 'nVidia Corporation'
device = 'GT218 [ION]'
class  = display
subclass   = VGA
hdac1@pci0:3:0:1:   class=0x040300 card=0x841f1043 chip=0x0be310de
rev=0xa1 hdr=0x00
vendor = 'nVidia Corporation'
device = 'High Definition Audio Controller'
class  = multimedia
subclass   = HDA
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-16 Thread Mickaël Maillot

2012/1/12 Alexander Motin m...@freebsd.org

 On 01/12/12 14:18, Yuri Pankov wrote:

 On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:

 I would like request for testing of my work on further HDA sound driver
 improvement.

 [...]

 Patch can be found here:
 http://people.freebsd.org/~**mav/hda.rewrite.patchhttp://people.freebsd.org/~mav/hda.rewrite.patch

 Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
 and 8-STABLE branches also.



i switched my htpc to 9-STABLE and applied the patch:

pcm0: Realtek ALC887 HDA CODEC PCM (Rear Analog) (play/rec)
pcm1: Realtek ALC887 HDA CODEC PCM (Front Analog) (play/rec)
pcm2: Realtek ALC887 HDA CODEC PCM (Rear Digital) (play) default
pcm3: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) (play)
pcm4: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) (play)
pcm5: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) (play)
pcm6: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) (play)

no regression found, i fully tested my optical output: mp3, ac3, dts no
problem.



  I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
 mplayer just pauses at the beggining, trying to cat anything to
 /dev/dsp{0-3}.0 gives:

 pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel
 dead

 It was the same with the old driver and I'm not sure if it's (most
 likely) my misconfiguration or a driver problem.


 It sounds more like a driver problem. HDMI audio is still not very well
 discovered area, and, according to ALSA reading, NVidia HDMI is also not
 very standard. Probably I'll finally have to buy something to experiment.
 What card do you have?


exaclty the same thing for me when i try my pcm3-6
it could be realy nice to have nvidia hdmi support first 2 channels and
next 8 channels.
i have an ION2 platform and i'm open to test everything.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-15 Thread Andriy Gapon

on 15/01/2012 00:17 Doug Barton said the following:
 On 01/14/2012 13:25, Steve Kargl wrote:
 Remove dvd insert music cd in drive, 'cdcontrol play'.  The
 drive is reading the cd and 'cdcontrol status' indicates
 that it is playing.  No sound.
 
 The way that this was explained to me (and I'm certainly no expert) is
 that in the ATA-CAM world the only way the access method used by
 cdcontrol will be able to play the music is if there is a direct (wired)
 connection from the cd player to the sound card, like we had back in the
 80's. :)  Other tools (such as vlc, mplayer, etc.) use the cdda://
 method of access, which does not rely on the wire.
 
 (As I understand it) this also explains why dvds work, but cds don't.

Just a note: this has nothing to do with ATA-CAM.  It has always been the case
for cdcontrol play.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-15 Thread Slawa Olhovchenkov

On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:

 I would like request for testing of my work on further HDA sound driver 
 improvement.

Can you add (or document, if exist) functionality of recording audio playing?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-15 Thread Alexander Motin


On 01/11/12 21:33, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound driver
improvement.


...


Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.

Special thanks to iXsystems, Inc. for supporting this work.

Comments and tests results are welcome!


Big thanks to everybody who tried it! As soon as no regressions were 
found, I've just committed slightly updated code into the HEAD branch. I 
plan to merge it down to 8/9-STABLE in about two months.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-15 Thread Yuri Pankov

On Thu, Jan 12, 2012 at 05:04:04PM +0400, Yuri Pankov wrote:
 On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:
  On 01/12/12 14:18, Yuri Pankov wrote:
   On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
   I would like request for testing of my work on further HDA sound driver
   improvement.
   [...]
   Patch can be found here:
   http://people.freebsd.org/~mav/hda.rewrite.patch
  
   Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
   and 8-STABLE branches also.
  
   Patch applied cleanly to r230008 using `svn patch`.
  
   hdacc0:NVidia GT220 HDA CODEC  at cad 0 on hdac0
   hdaa0:NVidia GT220 HDA CODEC Audio Function Group  at nid 1 on hdacc0
   pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)  at nid 5 on hdaa0
   hdacc1:NVidia GT220 HDA CODEC  at cad 1 on hdac0
   hdaa1:NVidia GT220 HDA CODEC Audio Function Group  at nid 1 on hdacc1
   pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)  at nid 5 on hdaa1
   hdacc2:NVidia GT220 HDA CODEC  at cad 2 on hdac0
   hdaa2:NVidia GT220 HDA CODEC Audio Function Group  at nid 1 on hdacc2
   pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)  at nid 5 on hdaa2
   hdacc3:NVidia GT220 HDA CODEC  at cad 3 on hdac0
   hdaa3:NVidia GT220 HDA CODEC Audio Function Group  at nid 1 on hdacc3
   pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)  at nid 5 on hdaa3
   hdacc4:IDT 92HD75BX HDA CODEC  at cad 0 on hdac1
   hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group  at nid 1 on hdacc4
   pcm4:IDT 92HD75BX HDA CODEC PCM (Analog)  at nid 13 and 11 on hdaa4
   pcm5:IDT 92HD75BX HDA CODEC PCM (Analog)  at nid 15 and 24 on hdaa4
   pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital)  at nid 30 on hdaa4
  
   pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however
  
  Thank you.
  
   I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
   mplayer just pauses at the beggining, trying to cat anything to
   /dev/dsp{0-3}.0 gives:
  
   pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel 
   dead
  
   It was the same with the old driver and I'm not sure if it's (most
   likely) my misconfiguration or a driver problem.
  
  It sounds more like a driver problem. HDMI audio is still not very well 
  discovered area, and, according to ALSA reading, NVidia HDMI is also not 
  very standard. Probably I'll finally have to buy something to 
  experiment. What card do you have?
 
 It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
 identified by x11/nvidia-driver).
 
 The verbose dmesg is at:
 
 https://www.xvoid.org/stuff/spica.dmesg

I'm getting the following panic as soon as I log into GNOME (wasn't
running it before, so I'm not sure if it's a problem with new driver
version or not, will test if needed):

panic: Stop for not allocated stream (1/0)

The full core.txt is at:

https://www.xvoid.org/stuff/core.txt.0


Thanks,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-15 Thread Alexander Motin


On 01/15/12 22:50, Yuri Pankov wrote:

On Thu, Jan 12, 2012 at 05:04:04PM +0400, Yuri Pankov wrote:

On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:

On 01/12/12 14:18, Yuri Pankov wrote:

On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound driver
improvement.

[...]

Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.


Patch applied cleanly to r230008 using `svn patch`.

hdacc0:NVidia GT220 HDA CODEC   at cad 0 on hdac0
hdaa0:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc0
pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa0
hdacc1:NVidia GT220 HDA CODEC   at cad 1 on hdac0
hdaa1:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc1
pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa1
hdacc2:NVidia GT220 HDA CODEC   at cad 2 on hdac0
hdaa2:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc2
pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa2
hdacc3:NVidia GT220 HDA CODEC   at cad 3 on hdac0
hdaa3:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc3
pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa3
hdacc4:IDT 92HD75BX HDA CODEC   at cad 0 on hdac1
hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group   at nid 1 on hdacc4
pcm4:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 13 and 11 on hdaa4
pcm5:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 15 and 24 on hdaa4
pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital)   at nid 30 on hdaa4

pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however


Thank you.


I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:

pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead

It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.


It sounds more like a driver problem. HDMI audio is still not very well
discovered area, and, according to ALSA reading, NVidia HDMI is also not
very standard. Probably I'll finally have to buy something to
experiment. What card do you have?


It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
identified by x11/nvidia-driver).

The verbose dmesg is at:

https://www.xvoid.org/stuff/spica.dmesg


I'm getting the following panic as soon as I log into GNOME (wasn't
running it before, so I'm not sure if it's a problem with new driver
version or not, will test if needed):

panic: Stop for not allocated stream (1/0)

The full core.txt is at:

https://www.xvoid.org/stuff/core.txt.0


Hmm. May be it is result of double stop. Please try this patch:

--- hdaa.c  (revision 230179)
+++ hdaa.c  (working copy)
@@ -1351,6 +1351,8 @@
struct hdaa_widget *w;
int i;

+   if ((ch-flags  HDAA_CHN_RUNNING) == 0)
+   return;
ch-flags = ~HDAA_CHN_RUNNING;
HDAC_STREAM_STOP(device_get_parent(devinfo-dev), devinfo-dev,
ch-dir == PCMDIR_PLAY ? 1 : 0, ch-sid);


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-15 Thread Yuri Pankov

On Mon, Jan 16, 2012 at 02:08:47AM +0200, Alexander Motin wrote:
 On 01/15/12 22:50, Yuri Pankov wrote:
  On Thu, Jan 12, 2012 at 05:04:04PM +0400, Yuri Pankov wrote:
  On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:
  On 01/12/12 14:18, Yuri Pankov wrote:
  On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
  I would like request for testing of my work on further HDA sound driver
  improvement.
  [...]
  Patch can be found here:
  http://people.freebsd.org/~mav/hda.rewrite.patch
 
  Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
  and 8-STABLE branches also.
 
  Patch applied cleanly to r230008 using `svn patch`.
 
  hdacc0:NVidia GT220 HDA CODEC   at cad 0 on hdac0
  hdaa0:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc0
  pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa0
  hdacc1:NVidia GT220 HDA CODEC   at cad 1 on hdac0
  hdaa1:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc1
  pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa1
  hdacc2:NVidia GT220 HDA CODEC   at cad 2 on hdac0
  hdaa2:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc2
  pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa2
  hdacc3:NVidia GT220 HDA CODEC   at cad 3 on hdac0
  hdaa3:NVidia GT220 HDA CODEC Audio Function Group   at nid 1 on hdacc3
  pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)   at nid 5 on hdaa3
  hdacc4:IDT 92HD75BX HDA CODEC   at cad 0 on hdac1
  hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group   at nid 1 on hdacc4
  pcm4:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 13 and 11 on hdaa4
  pcm5:IDT 92HD75BX HDA CODEC PCM (Analog)   at nid 15 and 24 on hdaa4
  pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital)   at nid 30 on hdaa4
 
  pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however
 
  Thank you.
 
  I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
  mplayer just pauses at the beggining, trying to cat anything to
  /dev/dsp{0-3}.0 gives:
 
  pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, 
  channel dead
 
  It was the same with the old driver and I'm not sure if it's (most
  likely) my misconfiguration or a driver problem.
 
  It sounds more like a driver problem. HDMI audio is still not very well
  discovered area, and, according to ALSA reading, NVidia HDMI is also not
  very standard. Probably I'll finally have to buy something to
  experiment. What card do you have?
 
  It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
  identified by x11/nvidia-driver).
 
  The verbose dmesg is at:
 
  https://www.xvoid.org/stuff/spica.dmesg
 
  I'm getting the following panic as soon as I log into GNOME (wasn't
  running it before, so I'm not sure if it's a problem with new driver
  version or not, will test if needed):
 
  panic: Stop for not allocated stream (1/0)
 
  The full core.txt is at:
 
  https://www.xvoid.org/stuff/core.txt.0
 
 Hmm. May be it is result of double stop. Please try this patch:
 
 --- hdaa.c  (revision 230179)
 +++ hdaa.c  (working copy)
 @@ -1351,6 +1351,8 @@
  struct hdaa_widget *w;
  int i;
 
 +   if ((ch-flags  HDAA_CHN_RUNNING) == 0)
 +   return;
  ch-flags = ~HDAA_CHN_RUNNING;
  HDAC_STREAM_STOP(device_get_parent(devinfo-dev), devinfo-dev,
  ch-dir == PCMDIR_PLAY ? 1 : 0, ch-sid);

Thanks, that did the trick.


Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 14.01.2012 04:10, Michael Schnell wrote:


On Thu, 12 Jan 2012, Yuri Pankov wrote:


On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:

On 01/12/12 14:18, Yuri Pankov wrote:

On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:

I would like request for testing of my work on further HDA sound
driver
improvement.

[...]

Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.


Patch applied cleanly to r230008 using `svn patch`.

hdacc0:NVidia GT220 HDA CODEC at cad 0 on hdac0
hdaa0:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1:NVidia GT220 HDA CODEC at cad 1 on hdac0
hdaa1:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2:NVidia GT220 HDA CODEC at cad 2 on hdac0
hdaa2:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3:NVidia GT220 HDA CODEC at cad 3 on hdac0
hdaa3:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4:IDT 92HD75BX HDA CODEC at cad 0 on hdac1
hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 13 and 11 on hdaa4
pcm5:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 15 and 24 on hdaa4
pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital) at nid 30 on hdaa4

pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine,
however


Thank you.


I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:

pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout,
channel dead

It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.


It sounds more like a driver problem. HDMI audio is still not very well
discovered area, and, according to ALSA reading, NVidia HDMI is also not
very standard. Probably I'll finally have to buy something to
experiment. What card do you have?


It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
identified by x11/nvidia-driver).

The verbose dmesg is at:

https://www.xvoid.org/stuff/spica.dmesg


I had the same problem for some time and I was going over the code and
honestly I took some inspiration of how the linux kernel handle this and
added some quirks to the code to get it working. However, after some
time I realize that a sysctl
dev.hdac.n.0.polling=1 will do something similar and this also works for
me. I don't think this polling mechanism is a good idea, better would be
some interrupt for state updates but anyway, I was glad that I can here
(digital) music over my receiver with my laptop. I have an NVS 3100M
graphic card and it is connected over a (fragile) Displayport-HDMI adapter.

I would gladly test this with Alexanders patch, but I only have an
9.0-RELEASE and I already tried to port the patch back, but this would
take some effort. In addition this is my production system and I already
messed it up enough. ;)


I also don't like polling, especially in context of new event timers 
that are not generating interrupts when not needed. In this patch I 
haven't even reimplemented polling support while rewriting that part of 
the code, as for several years since implementing it I haven't seen 
reports that it was really useful. If it is useful, I'll think of it.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Alexander Best

On Thu Jan 12 12, Rainer Hurling wrote:
 On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote:
 On 01/12/12 12:52, Gary Jennejohn wrote:
 On Wed, 11 Jan 2012 21:33:17 +0200
 Alexander Motinm...@freebsd.org wrote:
 I would like request for testing of my work on further HDA sound driver
 improvement.
 
 [big snip]
 
 Patch can be found here:
 http://people.freebsd.org/~mav/hda.rewrite.patch
 
 Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
 and 8-STABLE branches also.
 
 The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
 in size (mostly the section which deletes all the manufacturer-specific
 defines at the top of the file).
 
 That is probably because of $FreeBSD$ macro resolution. Here is version
 with present value from 10-CURRENT SVN (sources from CVS or STABLE will
 need that patch line modified respectively) and some minor additional
 improvements like CODEC ODs and some more sysctls:
 http://people.freebsd.org/~mav/hda.rewrite2.patch

maybe you could try silencencing these clang warnings?

/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format 
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 4.0);
  ^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format 
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 5.1);
  ^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format 
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 7.1);
 ^~
/usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if statement 
has empty body [-Wempty-body]
if ((child = codec-streams[dir][stream]) != NULL);
  ^
4 warning generated.

..i'll report how the changes interact with my system later on.

cheers.
alex

 
 
 I just patched 10.0-CURRENT (amd64) r230009 against hda.rewrite2.patch. 
 All went fine so far. My box is now running again with following messages:
 
 hdacc0: NVidia (Unknown) HDA CODEC at cad 0 on hdac0
 hdaa0: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc0
 pcm0: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
 hdacc1: NVidia (Unknown) HDA CODEC at cad 1 on hdac0
 hdaa1: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc1
 pcm1: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
 hdacc2: NVidia (Unknown) HDA CODEC at cad 2 on hdac0
 hdaa2: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc2
 pcm2: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
 hdacc3: NVidia (Unknown) HDA CODEC at cad 3 on hdac0
 hdaa3: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc3
 pcm3: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
 hdacc4: Realtek ALC892 HDA CODEC at cad 0 on hdac1
 hdaa4: Realtek ALC892 HDA CODEC Audio Function Group at nid 1 on hdacc4
 pcm4: Realtek ALC892 HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 
 20,22,23,21 and 24,26 on hdaa4
 pcm5: Realtek ALC892 HDA CODEC PCM (Front Analog) at nid 27 and 25 on 
 hdaa4
 pcm6: Realtek ALC892 HDA CODEC PCM (Rear Digital) at nid 30 on hdaa4
 pcm7: Realtek ALC892 HDA CODEC PCM (Onboard Digital) at nid 17 on hdaa4
 
 I am using pcm4 with 5.1 surround sound and pulseaudio. All seems to 
 work fine :-)
 
 The mainboard is an Asus M4A88TD-V EVO/USB3, the graphics card is a 
 NVidia GeForce GTS 450. The Realtek ALC892 is regocnized by the driver, 
 the NVidia HDMI sound device is not.
 
 I am looking forward to the commit of this patch!
 
 
 After fixing that per hand I was able to make a kernel with which sound
 still works. Here the relevant bits from dmesg:
 
 hdac0:NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq
 18 at device 0.1 on pci1
 hdac1:ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at
 device 20.2 on pci0
 hdacc0:NVidia GT21x HDA CODEC at cad 0 on hdac0
 hdaa0:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0
 pcm0:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
 hdacc1:NVidia GT21x HDA CODEC at cad 1 on hdac0
 hdaa1:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1
 pcm1:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
 hdacc2:NVidia GT21x HDA CODEC at cad 2 on hdac0
 hdaa2:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2
 pcm2:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
 hdacc3:NVidia GT21x HDA CODEC at cad 3 on hdac0
 hdaa3:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3
 pcm3:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
 hdacc4:Realtek ALC889A HDA CODEC at cad 0 on hdac1

Re: [RFT] Major snd_hda rewrite


On 01/14/12 15:48, Alexander Best wrote:

On Thu Jan 12 12, Rainer Hurling wrote:

On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote:

On 01/12/12 12:52, Gary Jennejohn wrote:

On Wed, 11 Jan 2012 21:33:17 +0200
Alexander Motinm...@freebsd.org  wrote:

I would like request for testing of my work on further HDA sound driver
improvement.


[big snip]


Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.


The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
in size (mostly the section which deletes all the manufacturer-specific
defines at the top of the file).


That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch


maybe you could try silencencing these clang warnings?

/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format 
string is not a string literal (potentially insecure) [-Wformat-security]
 snprintf(buf, buflen, chans = 4.0);
   ^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format 
string is not a string literal (potentially insecure) [-Wformat-security]
 snprintf(buf, buflen, chans = 5.1);
   ^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format 
string is not a string literal (potentially insecure) [-Wformat-security]
 snprintf(buf, buflen, chans = 7.1);
  ^~
/usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if statement 
has empty body [-Wempty-body]
 if ((child = codec-streams[dir][stream]) != NULL);
   ^
4 warning generated.

..i'll report how the changes interact with my system later on.


Thank you! That variable is not even used now, so I'll just remove that 
assignment. I've passed the code through the clang static analyzer at 
some point, but probably I've introduced that later.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Alexander Best

On Sat Jan 14 12, Alexander Motin wrote:
 On 01/14/12 15:48, Alexander Best wrote:
 On Thu Jan 12 12, Rainer Hurling wrote:
 On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote:
 On 01/12/12 12:52, Gary Jennejohn wrote:
 On Wed, 11 Jan 2012 21:33:17 +0200
 Alexander Motinm...@freebsd.org  wrote:
 I would like request for testing of my work on further HDA sound driver
 improvement.
 
 [big snip]
 
 Patch can be found here:
 http://people.freebsd.org/~mav/hda.rewrite.patch
 
 Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
 and 8-STABLE branches also.
 
 The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
 in size (mostly the section which deletes all the manufacturer-specific
 defines at the top of the file).
 
 That is probably because of $FreeBSD$ macro resolution. Here is version
 with present value from 10-CURRENT SVN (sources from CVS or STABLE will
 need that patch line modified respectively) and some minor additional
 improvements like CODEC ODs and some more sysctls:
 http://people.freebsd.org/~mav/hda.rewrite2.patch
 
 maybe you could try silencencing these clang warnings?
 
 /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format 
 string is not a string literal (potentially insecure) [-Wformat-security]
  snprintf(buf, buflen, chans = 4.0);
^
 /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format 
 string is not a string literal (potentially insecure) [-Wformat-security]
  snprintf(buf, buflen, chans = 5.1);
^
 /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format 
 string is not a string literal (potentially insecure) [-Wformat-security]
  snprintf(buf, buflen, chans = 7.1);
   ^~
 /usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if 
 statement has empty body [-Wempty-body]
  if ((child = codec-streams[dir][stream]) != NULL);
^
 4 warning generated.
 
 ..i'll report how the changes interact with my system later on.
 
 Thank you! That variable is not even used now, so I'll just remove that 
 assignment. I've passed the code through the clang static analyzer at 
 some point, but probably I've introduced that later.

thanks. :)

the patch works great for me, too.

dmesg -a:

hdacc0: Realtek ALC889A HDA CODEC at cad 2 on hdac0
hdaa0: Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,21,23 
and 24,26 on hdaa0
pcm1: Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa0
pcm2: Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31 on hdaa0

cat /dev/sndstat:

FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) on hdaa0  
(1p:1v/2r:1v) default
snddev flags=0x2e6AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x2108, 
0x0004
interrupts 1274, underruns 0, feed 1274, ready 0 
[b:16384/8192/2|bs:16384/8192/2]
channel flags=0x2108TRIGGERED,BUSY,HAS_VCHAN
{userland} - feeder_mixer(0x00200010) - {hardware}
pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000, fmt 
0x00200010, flags 0x112c, 0x0029, pid 927 (musicpd)
interrupts 0, underruns 0, feed 1859, ready 65536 
[b:0/0/0|bs:65536/8192/8]
channel flags=0x112cRUNNING,TRIGGERED,SLEEPING,BUSY,VIRTUAL
{userland} - feeder_root(0x00200010) - feeder_volume(0x00200010) - 
feeder_rate(0x00200010 q:1 44100 - 48000) - {hardware}
[pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags 0x2100, 
0x0005
interrupts 0, overruns 0, feed 0, hfree 16384, sfree 16384 
[b:16384/8192/2|bs:16384/8192/2]
channel flags=0x2100BUSY,HAS_VCHAN
{hardware} - feeder_root(0x00200010) - feeder_mixer(0x00200010) - 
{userland}
[pcm0:record:dsp0.r1]: spd 8000, fmt 0x0018, flags 0x, 
0x
interrupts 0, overruns 0, feed 0, hfree 65536, sfree 0 
[b:65536/32768/2|bs:0/0/0]
channel flags=0x0
{hardware} - feeder_root(0x) - {userland}
pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt 0x0018, 
flags 0x1000, 0x
interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000VIRTUAL
{hardware} - feeder_root(0x) - {userland}
pcm1: Realtek ALC889A HDA CODEC PCM (Front Analog) on hdaa0  (1p:1v/1r:1v)
snddev flags=0x2e6AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC
[pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010, flags 0x2100, 
0x0004
interrupts 0, underruns 0, feed 0, ready 0

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Mickaël Maillot

2012/1/11 Alexander Motin m...@freebsd.org

Hi.

I would like request for testing of my work on further HDA sound driver
improvement.

List of changes done this time:
- Huge old hdac driver was split into three independent pieces: HDA
controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function
driver (hdaa). All drivers are completely independent and talk to each
other only via NewBus interfaces. Using more NewBus bells and whistles
allows to properly see HDA structure with standard system instruments, such
as `devinfo -v`. Biggest driver file size now is 150K, instead of 240K
before, and the code is much more clean.
- Support for multichannel recording was added. While I've never seen it
configured by default, UAA specification tells that it is possible. Now, as
specification defines, driver checks input associations for pins with
sequence numbers 14 and 15, and if found (usually) -- works as before,
mixing signals together. If it doesn't, it configures input association as
multichannel. I've found some CODECs doing strange things when configured
for multichannel recording, but I've also found successfully working
examples.
- Signal tracer was improved to look for cases where several DACs/ADCs in
CODEC can work with the same audio signal. If such case found, driver
registers additional playback/record stream (channel) for the pcm device.
Having more then one stream allows to avoid vchans use and so avoid extra
conversion to pre-configured vchan rate and sample format. Not many CODECs
allow this, especially on playback, but some do.
- New controller streams reservation mechanism was implemented. That
allows to have more pcm devices then streams supported by the controller
(usually 4 in each direction). Now it limits only number of
_simultaneously_ transferred audio streams, that is rarely reachable and
properly reported if happens.
- Codec pins and GPIO signals configuration was exported via set of
writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger
driver reconfiguration in run-time. The only requirement is that all pcm
devices should be closed at the moment, as they will be destroyed and
recreated. This should significantly simplify process of fixing CODEC
configuration. It should be possible now even to write GUI to do it with
few mouse clicks.
- Driver now decodes pins location and connector type names. In some
cases it allows to hint user where on the system case connectors, related
to the pcm device, are located. Number of channels supported by pcm device,
reported now (if it is not 2), should also make search easier.
- Added fix for digital mic recording on some Asus laptops/netbooks.

That is how it may look now in dmesg:

hdac0: Intel 5 Series/3400 Series HDA Controller mem
0xf7ef4000-0xf7ef7fff irq 22 at device 27.0 on pci0
hdacc0: VIA VT1708S_0 HDA CODEC at cad 0 on hdac0
hdaa0: VIA VT1708S_0 HDA CODEC Audio Function Group at nid 1 on hdacc0
hdacc1: Intel Ibex Peak HDA CODEC at cad 3 on hdac0
hdaa1: Intel Ibex Peak HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm0: VIA VT1708S_0 HDA CODEC PCM (Analog) at nid 28,29 and 26,30,27 on
hdaa0
pcm1: VIA VT1708S_0 HDA CODEC PCM (Digital) at nid 32 on hdaa0
pcm2: Intel Ibex Peak HDA CODEC PCM (DisplayPort 8ch) at nid 6 on hdaa1

Patch can be found here:
http://people.freebsd.org/~**mav/hda.rewrite.patchhttp://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and
8-STABLE branches also.

Special thanks to iXsystems, Inc. for supporting this work.

Comments and tests results are welcome!

to much work for me to get it work on 8-STABLE (missing MFC of r227701,
r227849 and other things)
so i'll update my htpc to 9-STABLE.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Steve Kargl

On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:
 
 That is probably because of $FreeBSD$ macro resolution. Here is version 
 with present value from 10-CURRENT SVN (sources from CVS or STABLE will 
 need that patch line modified respectively) and some minor additional 
 improvements like CODEC ODs and some more sysctls:
 http://people.freebsd.org/~mav/hda.rewrite2.patch
 

Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780

Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.

Remove dvd insert music cd in drive, 'cdcontrol play'.  The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing.  No sound.

Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm}  {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 14.01.2012 23:25, Steve Kargl wrote:

On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:


That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch



Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780

Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.


You mean that speakers are not disabled when headphones are plugged in?

In PR you've written that no sound goes from speakers, but here tell 
opposite. What is right?



Remove dvd insert music cd in drive, 'cdcontrol play'.  The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing.  No sound.


Most likely analog audio output of your CD is not connected to the 
CODEC. At least there are no CODEC pin configured for it. You may try to 
configure different pins manually, but if there is no electrical 
connection...



Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm}  {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Steve Kargl

On Sat, Jan 14, 2012 at 11:39:43PM +0200, Alexander Motin wrote:
 On 14.01.2012 23:25, Steve Kargl wrote:
 On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:
 
 That is probably because of $FreeBSD$ macro resolution. Here is version
 with present value from 10-CURRENT SVN (sources from CVS or STABLE will
 need that patch line modified respectively) and some minor additional
 improvements like CODEC ODs and some more sysctls:
 http://people.freebsd.org/~mav/hda.rewrite2.patch
 
 
 Patch applied cleanly.
 Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780
 
 Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
 movie starts and sound comes from both the speakers and headphones.
 
 You mean that speakers are not disabled when headphones are plugged in?

No.  I mean that sound is available from either the speakers
(ie, no headphones) or from the headphones (ie no sound
from speakers).  That is, this is working as expected.

 In PR you've written that no sound goes from speakers, but here tell 
 opposite. What is right?

If the medium is a DVD, sound works.  If the medium is a music CD,
then sound does not work.

 Remove dvd insert music cd in drive, 'cdcontrol play'.  The
 drive is reading the cd and 'cdcontrol status' indicates
 that it is playing.  No sound.
 
 Most likely analog audio output of your CD is not connected to the 
 CODEC. At least there are no CODEC pin configured for it. You may try to 
 configure different pins manually, but if there is no electrical 
 connection...

Works with MS Windows XP.  Put music CD into drive.  Fire up
MediaPlayer and sound works.  So, I would assume that there
is an electrical connection.  So, how does one manually 
configure the pins?

 Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm}  {hda,snd,pcm.txt}'
 available at http://troutmask.apl.washington.edu/~kargl/hda/

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Doug Barton

On 01/14/2012 13:25, Steve Kargl wrote:
 Remove dvd insert music cd in drive, 'cdcontrol play'.  The
 drive is reading the cd and 'cdcontrol status' indicates
 that it is playing.  No sound.

The way that this was explained to me (and I'm certainly no expert) is
that in the ATA-CAM world the only way the access method used by
cdcontrol will be able to play the music is if there is a direct (wired)
connection from the cd player to the sound card, like we had back in the
80's. :)  Other tools (such as vlc, mplayer, etc.) use the cdda://
method of access, which does not rely on the wire.

(As I understand it) this also explains why dvds work, but cds don't.


hth,

Doug

-- 

You can observe a lot just by watching. -- Yogi Berra

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite


On 15.01.2012 00:10, Steve Kargl wrote:

On Sat, Jan 14, 2012 at 11:39:43PM +0200, Alexander Motin wrote:

On 14.01.2012 23:25, Steve Kargl wrote:

On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:


That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch



Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780

Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.


You mean that speakers are not disabled when headphones are plugged in?


No.  I mean that sound is available from either the speakers
(ie, no headphones) or from the headphones (ie no sound
from speakers).  That is, this is working as expected.


In PR you've written that no sound goes from speakers, but here tell
opposite. What is right?


If the medium is a DVD, sound works.  If the medium is a music CD,
then sound does not work.


Audio from DVDs always played by software after reading if from the disk 
as usual data. Audio CDs instead could be played either by the CD drive 
itself via analog audio connection or by software using digital audio 
extraction (reading from the disk).



Remove dvd insert music cd in drive, 'cdcontrol play'.  The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing.  No sound.


Most likely analog audio output of your CD is not connected to the
CODEC. At least there are no CODEC pin configured for it. You may try to
configure different pins manually, but if there is no electrical
connection...


Works with MS Windows XP.  Put music CD into drive.  Fire up
MediaPlayer and sound works.  So, I would assume that there
is an electrical connection.


I think no. Windows Media Player is able to play Audio CDs via digital 
audio extraction. 'cdcontrol play' just commands drive to play Audio CD. 
To play Audio CD via digital audio extraction use 'mplayer cdda://'.



So, how does one manually configure the pins?


Read man snd_hda, try, try, try, ... But most likely it is just not 
implemented in hardware.



Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm}   {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Steve Kargl

On Sun, Jan 15, 2012 at 12:31:51AM +0200, Alexander Motin wrote:
 Audio from DVDs always played by software after reading if from the disk 
 as usual data. Audio CDs instead could be played either by the CD drive 
 itself via analog audio connection or by software using digital audio 
 extraction (reading from the disk).

Thanks for the explanation.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite

2012-01-14 Thread Jan Beich

Alexander Motin m...@freebsd.org writes:

 I would like request for testing of my work on further HDA sound
 driver improvement.
[...]
  - Codec pins and GPIO signals configuration was exported via set of
 writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger
 driver reconfiguration in run-time. The only requirement is that all
 pcm devices should be closed at the moment, as they will be destroyed
 and recreated. This should significantly simplify process of fixing
 CODEC configuration. It should be possible now even to write GUI to do
 it with few mouse clicks.

reconfig seems to not honor hw.snd.default_unit sysctl. After
reconfiguration the sysctl was reset to `0' (default). Is this expected?
Even if it is specified as a tunable in loader.conf?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFT] Major snd_hda rewrite