Re: audio usemixer breaks vs(4) Re: CVS commit: src/sys/dev
Hi Nathanial, Tetsuya, (Christos) this is one more thank you to Nathanial for this awesome work. He's going to great length to make sure his changes work everywhere every time, and even then it is very, very difficult to achieve a net positive on every platform in every commit - we are supporting so many! Let's just be a bit nicer to each other, fix issues as we see them appear, and keep up the great work. Cheers, -- khorben On 08/11/2017 00:10, Nathanial Sloss wrote: > Hello Tetsuya and Christos, > > > On Tue, 7 Nov 2017 14:45:47 Tetsuya Isaki wrote: >> nat@, (cc: christos@) >> >> With this change, vs(4) no longer works even if usemixer=0. >> Please revert it, and don't break without public discussion. > > vs audio with the mixer enabled has been fixed in a follow up commit. > > The change was intended to benifit slow (antiquated) computers that may have > trouble with the extra code in the audio path with mixing enabled. > >> >> This is the 3rd time you broke vs(4). >> You broke and I repaired. >> You broke and I repaired. >> I spent a lot of time this half year. > > The reason as to why vs audio does not work with usemixer=0 is that you > decided to remove what you considered to be dead code (mulaw, alaw, unsigned > linear filters). > > The time I've spent on audio/ossaudio/bluetooth audio has been at least two > years non-stop and I will devote more time to it in future - so I think it's > fair to say we've all spent a lot of time perfecting NetBSD. > >> >> If you can not consider about supported devices (at least >> devices which has active users), please don't touch audio. >> > > Every time I make a change I test it with emulations of various computers, > usb > audio devices, all of the computers I own and bluetooth. > > Also an x68k emulation since x68k has been a problem with the changes. > > I think to hold the merits of what I done to audio to x68k's abilities to be > unfair. > > I'm actively trying to innovate and to bring NetBSD's audio server into the > 21 > century whist still providing a solution for legacy systems we support. > > I hope to contine to work on audio in future - if there is an emmense > objection from others I will stop audio completely and work on something else. > > NB: Since I've started to alter audio with regards to mixing and such, I've > received at least 30 thank you emails from strangers and NetBSD users - The > people we write NetBSD for. > > >> Thanks, > >> --- >> Tetsuya Isaki > > Best regards and I hope to collaborate with you on audio in future as it is a > mutual interest. > > Nat > >> >> At Tue, 7 Nov 2017 01:13:19 +, >> >>> Module Name:src >>> Committed By: nat >>> Date: Tue Nov 7 01:13:19 UTC 2017 >>> >>> Modified Files: >>> src/sys/dev: audio.c audiovar.h >>> >>> Log Message: >>> A sysctl is now available to disable the in kernel mixer. >>> >>> sysctl -w hw.hdafg0.usemixer=0 >>> >>> There currently is a problem draining the last block with the mixer >>> disabled. I will fix this in a follow up commit. >>> >>> AFAIK there will be a problem wiht vs(4) on x68k with the mixer disabled >>> as the filters for mulaw, alaw and unsigned linear have been removed post >>> audio mixing changes. >>> >>> Documentation for this sysctl variable will be made to audio.4 in a >>> follow up commit. >>> >>> Ok christos@. >>> >>> >>> To generate a diff of this commit: >>> cvs rdiff -u -r1.429 -r1.430 src/sys/dev/audio.c >>> cvs rdiff -u -r1.66 -r1.67 src/sys/dev/audiovar -- khorben signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/dev/sdmmc
On Wed, 8 Nov 2017, Pierre Pronchery wrote: Sorry, I could not guess that, and I currently do not have reliable Internet at home so I often have to work on this offline. I got this part to build, thought this was a net positive and decided to commit it so it can benefit others too. You are much better and faster than me at working on this, I am interested in this area but feel free to go ahead and commit what you have if you can improve it or get it to work. Your patch was more or less the same as mine :) I was waiting for the author of the original author to get it working on OpenBSD -- there's a non-trivial amount of work that needs to be done. The current bwfm sdio code doesn't do much more than read a device ID and then print a TODO message. It was enough for me to work out some kinks in our sdmmc stack, but it's quite a ways away from being ready to use.
Re: audio usemixer breaks vs(4) Re: CVS commit: src/sys/dev
Hello Tetsuya and Christos, On Tue, 7 Nov 2017 14:45:47 Tetsuya Isaki wrote: > nat@, (cc: christos@) > > With this change, vs(4) no longer works even if usemixer=0. > Please revert it, and don't break without public discussion. vs audio with the mixer enabled has been fixed in a follow up commit. The change was intended to benifit slow (antiquated) computers that may have trouble with the extra code in the audio path with mixing enabled. > > This is the 3rd time you broke vs(4). > You broke and I repaired. > You broke and I repaired. > I spent a lot of time this half year. The reason as to why vs audio does not work with usemixer=0 is that you decided to remove what you considered to be dead code (mulaw, alaw, unsigned linear filters). The time I've spent on audio/ossaudio/bluetooth audio has been at least two years non-stop and I will devote more time to it in future - so I think it's fair to say we've all spent a lot of time perfecting NetBSD. > > If you can not consider about supported devices (at least > devices which has active users), please don't touch audio. > Every time I make a change I test it with emulations of various computers, usb audio devices, all of the computers I own and bluetooth. Also an x68k emulation since x68k has been a problem with the changes. I think to hold the merits of what I done to audio to x68k's abilities to be unfair. I'm actively trying to innovate and to bring NetBSD's audio server into the 21 century whist still providing a solution for legacy systems we support. I hope to contine to work on audio in future - if there is an emmense objection from others I will stop audio completely and work on something else. NB: Since I've started to alter audio with regards to mixing and such, I've received at least 30 thank you emails from strangers and NetBSD users - The people we write NetBSD for. > Thanks, > --- > Tetsuya Isaki Best regards and I hope to collaborate with you on audio in future as it is a mutual interest. Nat > > At Tue, 7 Nov 2017 01:13:19 +, > > > Module Name:src > > Committed By: nat > > Date: Tue Nov 7 01:13:19 UTC 2017 > > > > Modified Files: > > src/sys/dev: audio.c audiovar.h > > > > Log Message: > > A sysctl is now available to disable the in kernel mixer. > > > > sysctl -w hw.hdafg0.usemixer=0 > > > > There currently is a problem draining the last block with the mixer > > disabled. I will fix this in a follow up commit. > > > > AFAIK there will be a problem wiht vs(4) on x68k with the mixer disabled > > as the filters for mulaw, alaw and unsigned linear have been removed post > > audio mixing changes. > > > > Documentation for this sysctl variable will be made to audio.4 in a > > follow up commit. > > > > Ok christos@. > > > > > > To generate a diff of this commit: > > cvs rdiff -u -r1.429 -r1.430 src/sys/dev/audio.c > > cvs rdiff -u -r1.66 -r1.67 src/sys/dev/audiovar.h
Re: CVS commit: src/sys/arch
>On 11/07/17 09:05, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Tue Nov 7 09:05:06 UTC 2017
>>
>> Modified Files:
>> src/sys/arch/arm/broadcom: bcm2835_intr.c
>> src/sys/arch/evbarm/rpi: rpi_machdep.c
>>
>> Log Message:
>> on RPI2, fix compile failure without options MULTIPROCESSOR.
>
>Is this really necessary?
Yes. As long as it is option, it should be able to select enable or disable.
And it is useful for problem-isolation and debugging. (at least for me)
>@@ -626,22 +627,30 @@ rpi_bootparams(void)
>> static void
>> rpi_bootstrap(void)
>> {
>> -#if defined(BCM2836)
>> -arm_cpu_max = 4;
>> -extern int cortex_mmuinfo;
>> +#ifdef BCM2836
>> +#define RPI_CPU_MAX 4
>
>Why #if defined() -> #ifdef?
>
>Also please don't mix whitespace and real changes.
>
>This causes merge conflicts for me on my FDTisation of RPI which I'm
>about to commit :(
sorry. I commited without thinking.
Is it better to revert the commit once?
--
ryo shimizu
Re: CVS commit: src/sys/dev/sdmmc
Could have saved yourself a lot of time if you had emailed me first, I've been sitting on this code since I ported bwfm but didn't commit it as the original code doesn't actually work. Do you plan on finishing it? On Tue, 7 Nov 2017, Pierre Pronchery wrote: Module Name:src Committed By: khorben Date: Tue Nov 7 16:30:32 UTC 2017 Modified Files: src/sys/dev/sdmmc: files.sdmmc Added Files: src/sys/dev/sdmmc: if_bwfm_sdio.c Log Message: Add driver for Broadcom 802.11a/b/g/n/ac SDIO wireless devices, based on the OpenBSD bwfm(4) driver. I could not test this on any hardware yet, as it does not attach as-is on my Raspberry PI 3. To generate a diff of this commit: cvs rdiff -u -r1.4 -r1.5 src/sys/dev/sdmmc/files.sdmmc cvs rdiff -u -r0 -r1.1 src/sys/dev/sdmmc/if_bwfm_sdio.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch
On 11/07/17 09:05, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Tue Nov 7 09:05:06 UTC 2017
Modified Files:
src/sys/arch/arm/broadcom: bcm2835_intr.c
src/sys/arch/evbarm/rpi: rpi_machdep.c
Log Message:
on RPI2, fix compile failure without options MULTIPROCESSOR.
Is this really necessary?
@@ -626,22 +627,30 @@ rpi_bootparams(void)
static void
rpi_bootstrap(void)
{
-#if defined(BCM2836)
- arm_cpu_max = 4;
- extern int cortex_mmuinfo;
+#ifdef BCM2836
+#define RPI_CPU_MAX4
Why #if defined() -> #ifdef?
Also please don't mix whitespace and real changes.
This causes merge conflicts for me on my FDTisation of RPI which I'm
about to commit :(
Nick
