Re: [RFT] Major snd_hda rewrite
2012/1/28 Alexander Motin m...@freebsd.org You are right. Fixed: http://svn.freebsd.org/**changeset/base/230641http://svn.freebsd.org/changeset/base/230641 Thank you! -- Alexander Motin And i can play DTS-HDMA en Dolby TrueHD ! thanks for all your work :) ___ 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 Commenting it appeared not good, as at least mplayer doesn't sets channels for AC3. That makes sound(4) use default 1 channel for AC3, that is definitely not supported. I believe this should be better: http://svn.freebsd.org/**changeset/base/230537http://svn.freebsd.org/changeset/base/230537 Also, as soon as sound(4) interprets 8 channel as 7.1 by default, I've changed previous patch a bit to allow both 8.0 and 7.1 AC3 formats: http://svn.freebsd.org/**changeset/base/230513http://svn.freebsd.org/changeset/base/230513 thank, i can set 8 channels without vchan now. For me this at least doesn't break normal AC3 operation and when I hacked mplayer to set 8 channels, I can see predictable codec configuration and time in mplayer predictably running 4 times faster. Unluckily mplayer seems doesn't support TrueHD passthrough to ckeck closer -- it always does decoding. ok i think i found the problem: in http://svn.freebsd.org/changeset/base/230511 cchn is equal to 7 for me if i set SNDCTL_DSP_CHANNELS to 8. and it's why HBR bit is not set. it's confirmed in my /v/l/messages where chan_count=0x7: Jan 28 03:23:53 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02800400 (7.1) speed=192000 Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1 ___ 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/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
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
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
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/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/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/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/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/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! Hi, first thank for your work ! i'll try the patch this week end. DisplayPort 8ch : does it mean that we now support 8 channel PCM over DisplayPort and HDMI ? i need this feature for DTS-HDMA and TrueHD with XBMC. ___ 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: sata port multiplier
2011/8/5 Mike Tancsa m...@sentex.net On 8/4/2011 9:59 PM, Nenhum_de_Nos wrote: hail, any info on what port multiplier I could buy to make the 4 port Sil3124 at least make up to 8 ? speaking about PM, does anybody already tried new usb3 pm ? ___ 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: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.
Hi, 2011/5/8 Jason Hellenthal jh...@dataix.net List, - Please reply-to freebsd...@freebsd.org What does it do ?: As stated above, current functionality is undisturbed while allowing the user to create config's by any name they so desire as long as it has an extension of .conf, also introducing the ability to turn a configuration file off by using chmod(1). You can turn nfsc1.conf off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf seams not to be included in your patch, unless you change the line (or i'm wrong): if [ -f $_modular_conf ]; then by if [ -x $_modular_conf ]; then Why ? Simple. How many times have you been bitten by disabling something in the rc.conf file and left to discover what you just disabled was also used by another daemon but that daemon is now not starting ? This is a way to virtualize your configuration allowing you to add multiple _enable= lines to different configurations for different roles. For instance rpcbind is used by both samba and nfs*. With this you can add rpcbind_enable to both a configuration for samba and nfs and when you disable one service you know that you have not disabled a dependent for another. i resolved that by making multiple files source the same conf file. today my biggest problem is bad rc.d script like apache22, postfix, clamd or haproxy who load_rc_config and after overwrite extra_commands variable. this prevent me to add extra commands from a /etc/rc.conf.d/$name file. ___ 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: Any success stories for HAST + ZFS?
Hi, 2011/3/24 Freddie Cash fjwc...@gmail.com: The hardware is fairly standard fare: - SuperMicro H8DGi-F motherboard - AMD Opteron 6100-series CPU (8-cores @ 2.0 GHz) - 8 GB DDR3 SDRAM - 64 GB Kingston V-Series SSD for the OS install (using ahci(4) and the motherboard SATA controller) - 3x SuperMicro AOC-USAS2-8Li SATA controllers with IT firmware - 6x 1.5 TB Seagate 7200.11 drives (1x raidz2 vdev) - 12x 1.0 TB Seagate 7200.12 drives (2x raidz2 vdev) - 6x 0.5 TB WD RE3 drives (1x raidz2 vdev) just for info, sun recommend 1 Gb of RAM per Tera of data. i see here ~ 16 To of available data, so i would recommend 16 Gb for arc_size and 24 or 32 Gb for the host. ___ 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: [CFT] ZFS v15 patch (version 3)
patch works fine here on 8-STABLE. my deadlock probleme seams to be corrected (after 6h of zfs receive + find | wc -l + many small reads). 2010/7/10 Peter Jeremy peterjer...@acm.org: On 2010-Jul-08 23:30:33 +0200, Martin Matuska m...@freebsd.org wrote: Looking at the patchset, the most critical issue (IMHO) that doesn't appear to have been addressed is the interaction between ZFS ARC and the VM cache used by UFS/NFS: arc_memory_throttle() is still making decisions solely on the amount of free memory, without considering inactive or cache. I am running a slight variant of a patch by ... Regarding ARC, you might want to try the revision 209227 from head that is scheduled for MFC on 18.7.2010: http://people.freebsd.org/~mm/patches/zfs/head-12636.patch That patch appears to address issues with unreasonable arc sizing but doesn't alter the throttling algorithm: FreeBSD's traditional VM management algorithm (used by everything except ZFS) minimises space marked as free by preferentially keeping cached data in the cache or inactive queues. ZFS uses its own caching which solely uses the free list to determine memory availability. This means ZFS can't apply any pressure to the FreeBSD VM system and runs in a virtually permanent state of memory starvation. In any case, I have applied that patch as it appears useful. -- Peter Jeremy ___ 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: ZFS Stability MySQL (Comments Requested)
i have two freebsd running MySQL 5.1 on ZFS: - first: a 7-STABLE build (7.2, 2 month after zfs v13 import) the machine crash recently after a 130 day uptime beceause i dont limit arc size (so 4Gb by default) and i think they run oom. even with vfs.zfs.cache_flush_disable=1, no data loose, innodb redo the log and the mysql is fine. - second: a 8-STABLE FreeBSD db4.security-mail.net 8.0-STABLE FreeBSD 8.0-STABLE #2: Mon Apr 19 12:48:20 CEST 2010 r...@db4.security-mail.net:/usr/obj/usr/src/sys/GENERIC amd64) updated recently, no problem at all. i follow all opensolaris databases recommendation but there is some diff between freebsd and osol. like primarycache=metadata we have a realy big table (~ 1,5 To) in innodb split with mysql partition (compress ration ~ x2) and it's works pretty well. i would recommend you to wait 8.1 to have all recent zfs enhancement for prod unless you follow all mailing list and commit. 2010/4/29 Jason J. W. Williams jasonjwwilli...@gmail.com: Hi Olivier, We've actually been running MySQL on ZFS on Solaris for quite some time. :) We're very comfortable with that setup. My question is more specific to live experience with doing the same thing on FreeBSD. We know where the sabots are on MySQL/ZFS/Solaris. Would like to find out where the landmines are when you swap Solaris for FreeBSD in that equation. Thank you again. -J On Thu, Apr 29, 2010 at 8:48 AM, Olivier Smedts oliv...@gid0.org wrote: 2010/4/29 Jason J. W. Williams jasonjwwilli...@gmail.com: Hi Y'all, I've written before that we're considering moving to FreeBSD 8 from OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs ZFS implementation for a high reliability environment like a database? If so, what are your experiences? Basically, I'm curious how stable the implementation is and whether it's ready for a critical production environment. Also, any gotchas particularly with running it with MySQL or anything else that utilizes a lot of memory. On Solaris, we cap the max ARC size to keep it from grabbing all the system RAM and competing with MySQL. Any thoughts or comments are greatly appreciated. No experience with databases on ZFS but I think you should set the recordsize property to a proper (I mean, for your MySQL setup) value on the FS that will hold the data. Have a look at : http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases Cheers -J ___ 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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 ___ 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
