Re: Audio mixer and mixer control
Am 11.04.2020 um 06:57 schrieb O'Connor, Daniel via freebsd-stable: … So if I have dsp0 with line-in and line-out, and dsp3 with a S/PDIF out, there's no way to get the dsp0-"mix" over to dsp3? You can't use mixer to do what you want, but you can probably do something with a sox pipe line that would read from one input and feed to another if that is indeed what you need. What I'm looking for is a mixer which processes various input sources and sends them to arbitrary output devices. Does anybody know if there's such kind of mixer available? Or is it possible to interconnect different dsp channels? (ugh, I don't really know anything about contemporary audio hardware :-( ) I also have problems understanding the mixer(8) channels. Hard to find the corresponding dsp channel... The relation of "speaker", "mix", the invible "monitor" and "rec" is completely unclear to me, likewise the difference of "vol" and "pcm". Is it common that S/PDIF out is a separate dsp? I never had to investigate on other OS, where I get the same signal on analog and digital outputs simultaniously. I don't think it's very uncommon, although I haven't used FreeBSD on a desktop for quite a while.. What does this output? cat /dev/sndstat If you just want to play some audio out to the S/PDIF you can tell your audio program to use that particular device (eg /dev/dsp1 or whatever it is) Hello and thanks for your help. Main issue is to playback simultaniously on more than one dsp (musicpd(1) is providing that feature out of the box, but I was looking for a more general way, covering mixed line-in (DAB+ radio)). Here's my sndstat: FreeBSD Audio Driver (64bit 2009061500/amd64) Installed devices: pcm0: on hdaa0 (1p:2v/1r:2v) default pcm1: on hdaa0 (1p:2v/1r:1v) pcm2: on hdaa0 (1p:1v/0r:0v) pcm3: on hdaa0 (1p:1v/0r:0v) pcm4: at ? kld snd_uaudio (0p:0v/1r:1v) No devices installed from userspace. To my surprise, today there's dsp0_line-in/mix signal on dsp1_line-out. No idea if it was a layer 8 error yesterday (pretty sure it was not) or if some smart chip on the mainboard decided to interconnect over night (no reboot)?!? In fact, adjusting "mix" on dsp0 controls the output volume on dsp1 (analog line-in on dsp0 get's somehow routed to analog out on dsp1 (killed pulseaudio, nothing else is running, so it must be done in hardware)). I'd like to share what I discovered while browsing freshports.org/audio: rawrec(1) might be the leanest way to pipe signals, like you mentioned using sox(1). virtual_oss(8) seems to do exactly what I was looking for regarding "mixing". No idea how cuse(3) comes into play, seems to be not as native as I prefer things. Unfortunately, I don't have time to play with at the moment. But once I come back to it, I'll find it here for reference ;-) Thanks, -harry ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Audio mixer and mixer control
> On 11 Apr 2020, at 17:28, Harry Schmalzbauer wrote: > Hello and thanks for your help. Main issue is to playback simultaniously on > more than one dsp (musicpd(1) is providing that feature out of the box, but I > was looking for a more general way, covering mixed line-in (DAB+ radio)). I am not sure there is a general solution in the kernel. > Here's my sndstat: > FreeBSD Audio Driver (64bit 2009061500/amd64) > Installed devices: > pcm0: on hdaa0 (1p:2v/1r:2v) default > pcm1: on hdaa0 (1p:2v/1r:1v) > pcm2: on hdaa0 (1p:1v/0r:0v) > pcm3: on hdaa0 (1p:1v/0r:0v) > pcm4: at ? kld snd_uaudio (0p:0v/1r:1v) > No devices installed from userspace. OK, looks fairly normal.. BTW you can get more information with.. sudo sysctl hw.snd.verbose=2 cat /dev/sndstat > To my surprise, today there's dsp0_line-in/mix signal on dsp1_line-out. No > idea if it was a layer 8 error yesterday (pretty sure it was not) or if some > smart chip on the mainboard decided to interconnect over night (no reboot)?!? > In fact, adjusting "mix" on dsp0 controls the output volume on dsp1 (analog > line-in on dsp0 get's somehow routed to analog out on dsp1 (killed > pulseaudio, nothing else is running, so it must be done in hardware)). That sounds pretty peculiar, I guess it could be an result of the fact your 4 PCM devices are really 1 piece of hardware.. > I'd like to share what I discovered while browsing freshports.org/audio: > rawrec(1) might be the leanest way to pipe signals, like you mentioned using > sox(1). Yep, looks like it. > virtual_oss(8) seems to do exactly what I was looking for regarding "mixing". > No idea how cuse(3) comes into play, seems to be not as native as I prefer > things. Yes, it does - I haven't used it but it looks like what you want. cuse is for allowing device drivers in user land, I don't think it's required for virtual_oss, just that the same author wrote both :) > Unfortunately, I don't have time to play with at the moment. But once I come > back to it, I'll find it here for reference ;-) Good find, best of luck! -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS server has gone crazy slow
I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror (of two GPT disks) as it’s disk. It’s many years old, and has only been misbehaving like this for a day or so. I’m trying to figure out what’s wrong. I confirmed that internet connectivity isn’t the problem, and a reboot didn’t fix it. (The reboot took 10-15 minutes to finish going multi-user, starting daemons, due to the underlying problem described below.) Truss’ing a very basic command (date), I can see that close() and exit() calls are taking 1-2 seconds. All of the files being opened are on ZFS, but I don’t know if that’s for sure related. Similarly, using shell builtin “echo foo” always is immediate, but “/bin/echo” sometimes works quickly, but sometimes the close() on /var/run/ld-elf.so.hints takes 3-5 seconds. I _think_ this is a filesystem problem. It’s very hard to diagnose because logging in, and doing anything, takes many seconds per command. zpool status shows my mirror as online, so I’m not sure where I should check. I’d appreciate any help! Thanks much… - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS server has gone crazy slow
12.04.2020 0:36, Chris Ross wrote: > I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror (of > two GPT disks) as it’s disk. It’s many years old, and has only been > misbehaving like this for a day or so. I’m trying to figure out what’s wrong. > > I confirmed that internet connectivity isn’t the problem, and a reboot didn’t > fix it. (The reboot took 10-15 minutes to finish going multi-user, starting > daemons, due to the underlying problem described below.) > > Truss’ing a very basic command (date), I can see that close() and exit() > calls are taking 1-2 seconds. All of the files being opened are on ZFS, but > I don’t know if that’s for sure related. Similarly, using shell builtin > “echo foo” always is immediate, but “/bin/echo” sometimes works quickly, but > sometimes the close() on /var/run/ld-elf.so.hints takes 3-5 seconds. > > I _think_ this is a filesystem problem. It’s very hard to diagnose because > logging in, and doing anything, takes many seconds per command. zpool status > shows my mirror as online, so I’m not sure where I should check. > > I’d appreciate any help! Thanks much… First of all you should check if any of your ZFS pools is low on space. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS server has gone crazy slow
> On Apr 11, 2020, at 14:33, Eugene Grosbein wrote: > > 12.04.2020 0:36, Chris Ross wrote: > >> I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror >> (of two GPT disks) as it’s disk. It’s many years old, and has only been >> misbehaving like this for a day or so. I’m trying to figure out what’s >> wrong. >> >> […] >> >> I _think_ this is a filesystem problem. It’s very hard to diagnose because >> logging in, and doing anything, takes many seconds per command. zpool >> status shows my mirror as online, so I’m not sure where I should check. >> >> I’d appreciate any help! Thanks much… > > First of all you should check if any of your ZFS pools is low on space. Wow. I’m so embarrassed that I didn’t notice that myself. You mentioned it, and now I look back at df output and see that the filesystems are all very nearly full! It’s very slowly booting now, but assumedly after it comes online, I’ll be able to rectify that situation and hopefully that will be the issue. Thanks, and sorry that I hadn’t seen that myself! - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS server has gone crazy slow
Chris Ross writes: Wow. I’m so embarrassed that I didn’t notice that myself. You mentioned it, and now I look back at df output and see that the filesystems are all very nearly full! It’s very slowly booting now, but assumedly after it comes online, I’ll be able to rectify that situation and hopefully that will be the issue. Thanks, and sorry that I hadn’t seen that myself! Hi, It might be worth to remove old snapshots referring to files you are about to delete. Even if you remove a lot of files the space won't be really reclaimed until you delete any references in snapshots to these removed files, if that makes sense. You should also consider to add a periodic scrub of your pool, once a week for consumer disks or once a month for enterprise disks, or what have you. Regards, Oscar ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Audio mixer and mixer control
On 2020-04-11 04:20, O'Connor, Daniel via freebsd-stable wrote: virtual_oss(8) seems to do exactly what I was looking for regarding "mixing". No idea how cuse(3) comes into play, seems to be not as native as I prefer things. Yes, it does - I haven't used it but it looks like what you want. cuse is for allowing device drivers in user land, I don't think it's required for virtual_oss, just that the same author wrote both :) Cuse is required for virtual_oss (to implement OSS /dev/dsp interface), and it is indeed part of base FreeBSD, just not loaded into kernel by default. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why is the console a graphic/bitmapped console, and not text/character by default
Sorry for the ling title. But wasn't sure how make my question more concise. Why did we begin making an initial console "graphics mode" by default. My understanding has always been that (Free)BSD has been a "Server by default", and a Desktop after an initial install if that's one chosen target. It's near impossible to perform initial configuration in graphics mode, using a mouse to cut/copy/paste does *not* work as intended. Which requires one to make the necessary changes "breaking to the new system" after install completes to change initiation to test-mode before bouncing the box. While this "works" for long-time users. It's an *extra*, and seemingly *unnecessary* step. It is also likely to behoove first-time/new users -- except those already targeting a Desktop. Thanks for any insight into this! :) --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS server has gone crazy slow
12.04.2020 2:25, Chris Ross пишет: > >> On Apr 11, 2020, at 14:33, Eugene Grosbein wrote: >> >> 12.04.2020 0:36, Chris Ross wrote: >> >>> I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror >>> (of two GPT disks) as it’s disk. It’s many years old, and has only been >>> misbehaving like this for a day or so. I’m trying to figure out what’s >>> wrong. >>> >>> […] >>> >>> I _think_ this is a filesystem problem. It’s very hard to diagnose because >>> logging in, and doing anything, takes many seconds per command. zpool >>> status shows my mirror as online, so I’m not sure where I should check. >>> >>> I’d appreciate any help! Thanks much… >> >> First of all you should check if any of your ZFS pools is low on space. > > Wow. I’m so embarrassed that I didn’t notice that myself. You mentioned it, > and now I look back at df output and see that the filesystems are all very > nearly full! > > It’s very slowly booting now, but assumedly after it comes online, I’ll be > able to rectify that situation and hopefully that will be the issue. Thanks, > and sorry that I hadn’t seen that myself! There is very simple way to prevent such problem, use: zfs set reservation=1G for single "root" file system of the pool. This way ZFS won't allow applications to fill the pool to the point it starts crawling. Instead, writing applications would obtain ENOSPC error when pool's free space hits the limit. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why is the console a graphic/bitmapped console, and not text/character by default
12.04.2020 11:41, Chris wrote: > Sorry for the ling title. But wasn't sure how make my > question more concise. > Why did we begin making an initial console "graphics mode" > by default. My understanding has always been that (Free)BSD > has been a "Server by default", and a Desktop after an initial > install if that's one chosen target. > It's near impossible to perform initial configuration > in graphics mode, using a mouse to cut/copy/paste does *not* > work as intended. Which requires one to make the necessary > changes "breaking to the new system" after install completes > to change initiation to test-mode before bouncing the box. > While this "works" for long-time users. It's an *extra*, and > seemingly *unnecessary* step. It is also likely to behoove > first-time/new users -- except those already targeting a > Desktop. > > Thanks for any insight into this! :) There are now many new hardware incapable of booting in legacy mode. It runs in UEFI mode only that needs newer console driver vt(4) that defaults to pixel rendering mode but supports text mode, too. Sadly, some UEFI-based hardware does not support text mode even with vt(4) and there is no option other than using pixel mode then. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why is the console a graphic/bitmapped console, and not text/character by default
On Sun, 12 Apr 2020 12:55:47 +0700 Eugene Grosbein eu...@grosbein.net said 12.04.2020 11:41, Chris wrote: > Sorry for the ling title. But wasn't sure how make my > question more concise. > Why did we begin making an initial console "graphics mode" > by default. My understanding has always been that (Free)BSD > has been a "Server by default", and a Desktop after an initial > install if that's one chosen target. > It's near impossible to perform initial configuration > in graphics mode, using a mouse to cut/copy/paste does *not* > work as intended. Which requires one to make the necessary > changes "breaking to the new system" after install completes > to change initiation to test-mode before bouncing the box. > While this "works" for long-time users. It's an *extra*, and > seemingly *unnecessary* step. It is also likely to behoove > first-time/new users -- except those already targeting a > Desktop. > > Thanks for any insight into this! :) There are now many new hardware incapable of booting in legacy mode. It runs in UEFI mode only that needs newer console driver vt(4) that defaults to pixel rendering mode but supports text mode, too. Sadly, some UEFI-based hardware does not support text mode even with vt(4) and there is no option other than using pixel mode then. That explains it. Thanks Eugene! :) Even if the answer is a bit disappointing. ;) --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
