Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Em 07-09-2011 00:37, Devin Heitmueller escreveu: > On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab > wrote: >>> Basically the above starts at the *maximum* capture resolution and >>> works its way down. One might argue that this heuristic makes more >>> sense anyway - why *wouldn't* you want the highest quality audio >>> possible by default (rather than the lowest)? >> >> That change makes sense to me. Yet, you should try to disable pulseaudio >> and see what's the _real_ speed that the audio announces. On Fedora, >> just removing pulsaudio-oss-plugin (or something like that) is enough. >> >> It seems doubtful that my em2820 WinTV USB2 is different than yours. >> I suspect that pulseaudio is passing the "extra" range, offering to >> interpolate the data. > > I disabled pulseaudio and the capture device is advertising the exact > same range (8-48 KHz). Seems to be behaving the same way as well. Hmm... just checked with WinTV USB2: [3.819236] msp3400 15-0044: MSP3445G-B8 found @ 0x88 (em28xx #0) While this device uses snd-usb-audio, it is a non-AC97 adapter. So, we may expect it to be different from yours. Its A/D works at a fixed rate of 32 kHZ, according with MSP34x5G datasheet, so snd-usb-audio is working properly here. > So while I'm usually willing to blame things on Pulse, this doesn't > look like the case here. That's good. One less problem to deal with. >>> Even with that patch though, I hit severe underrun/overrun conditions >>> at 30ms of latency (to the point where the audio is interrupted dozens >>> of times per second). >> >> Yes, it is the same here: 30ms on my notebook is not enough for WinTV >> USB2 (it is OK with HVR-950). >> >>> Turned it up to 50ms and it's much better. >>> That said, of course such a change would impact lipsync, so perhaps we >>> need to be adjusting the periods instead. >> >> We've added a parameter for that on xawtv3 (--alsa-latency). We've >> parametrized >> it at the alsa stream function call. So, all it needs is to add a new >> parameter >> at tvtime config file. > > Ugh. We really need some sort of heuristic to do this. It's > unreasonable to expect users to know about some magic parameter buried > in a config file which causes it to start working. Agreed, but still it makes sense to allow users to adjust, as extra delays might be needed on really slow machines. > Perhaps a counter > that increments whenever an underrun is hit, and after a certain > number it automatically restarts the stream with a higher latency. Or > perhaps we're just making some poor choice in terms of the > buffers/periods for a given rate. > > Devin > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Hi, Lots of good stuff in this thread! It seems Mauro has answered most things, so I'm just going to respond to this bit. On 09/07/2011 05:37 AM, Devin Heitmueller wrote: We've added a parameter for that on xawtv3 (--alsa-latency). We've parametrized it at the alsa stream function call. So, all it needs is to add a new parameter at tvtime config file. Ugh. We really need some sort of heuristic to do this. It's unreasonable to expect users to know about some magic parameter buried in a config file which causes it to start working. Perhaps a counter that increments whenever an underrun is hit, and after a certain number it automatically restarts the stream with a higher latency. Or perhaps we're just making some poor choice in terms of the buffers/periods for a given rate. This may have something to do with usb versus pci capture, on my bttv card 30 ms works fine, but I can imagine it being a bit on the low side when doing video + audio capture over USB. So maybe should default to say 50 for usb capture devices and 30 for pci capture devices? In the end if people load there system enough / have a slow enough system our default will always be wrong for them. All we can do is try to get a default which is sane for most setups ... Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:42 PM, Devin Heitmueller wrote: > One more thing worth noting before I quit for the night: > > What audio processor is on your WinTV USB 2 device? The DVC-90 has an > emp202. Perhaps the WInTV uses a different audio processor (while > still using an em2820 as the bridge)? That might explain why your > device advertises effectively only one capture rate (32), while mine > advertises a whole range (8-48). Just took a look at the driver code. Seems we are calling em28xx_analog_audio_set() even if it's not using vendor audio. And that function actually hard-codes the rate to 48KHz. So here's the question: if using snd-usb-audio, should we really be poking at the AC97 registers at all? It seems that doing such can just get the audio processor state out of sync with however snd-usb-audio set it up. For example, the snd-usb-audio driver may very well be configuring the audio to 32 KHz, and then we reset the chip's state to 48Khz when we start streaming without the snd-usb-audio driver's knowledge. It seems like we should only be setting up the AC97 registers if it's an AC97 audio processor *and* it's using vendor audio. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:37 PM, Devin Heitmueller wrote: > On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab > wrote: >>> Basically the above starts at the *maximum* capture resolution and >>> works its way down. One might argue that this heuristic makes more >>> sense anyway - why *wouldn't* you want the highest quality audio >>> possible by default (rather than the lowest)? >> >> That change makes sense to me. Yet, you should try to disable pulseaudio >> and see what's the _real_ speed that the audio announces. On Fedora, >> just removing pulsaudio-oss-plugin (or something like that) is enough. >> >> It seems doubtful that my em2820 WinTV USB2 is different than yours. >> I suspect that pulseaudio is passing the "extra" range, offering to >> interpolate the data. > > I disabled pulseaudio and the capture device is advertising the exact > same range (8-48 KHz). Seems to be behaving the same way as well. > > So while I'm usually willing to blame things on Pulse, this doesn't > look like the case here. > >>> Even with that patch though, I hit severe underrun/overrun conditions >>> at 30ms of latency (to the point where the audio is interrupted dozens >>> of times per second). >> >> Yes, it is the same here: 30ms on my notebook is not enough for WinTV >> USB2 (it is OK with HVR-950). >> >>> Turned it up to 50ms and it's much better. >>> That said, of course such a change would impact lipsync, so perhaps we >>> need to be adjusting the periods instead. >> >> We've added a parameter for that on xawtv3 (--alsa-latency). We've >> parametrized >> it at the alsa stream function call. So, all it needs is to add a new >> parameter >> at tvtime config file. > > Ugh. We really need some sort of heuristic to do this. It's > unreasonable to expect users to know about some magic parameter buried > in a config file which causes it to start working. Perhaps a counter > that increments whenever an underrun is hit, and after a certain > number it automatically restarts the stream with a higher latency. Or > perhaps we're just making some poor choice in terms of the > buffers/periods for a given rate. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > One more thing worth noting before I quit for the night: What audio processor is on your WinTV USB 2 device? The DVC-90 has an emp202. Perhaps the WInTV uses a different audio processor (while still using an em2820 as the bridge)? That might explain why your device advertises effectively only one capture rate (32), while mine advertises a whole range (8-48). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab wrote: >> Basically the above starts at the *maximum* capture resolution and >> works its way down. One might argue that this heuristic makes more >> sense anyway - why *wouldn't* you want the highest quality audio >> possible by default (rather than the lowest)? > > That change makes sense to me. Yet, you should try to disable pulseaudio > and see what's the _real_ speed that the audio announces. On Fedora, > just removing pulsaudio-oss-plugin (or something like that) is enough. > > It seems doubtful that my em2820 WinTV USB2 is different than yours. > I suspect that pulseaudio is passing the "extra" range, offering to > interpolate the data. I disabled pulseaudio and the capture device is advertising the exact same range (8-48 KHz). Seems to be behaving the same way as well. So while I'm usually willing to blame things on Pulse, this doesn't look like the case here. >> Even with that patch though, I hit severe underrun/overrun conditions >> at 30ms of latency (to the point where the audio is interrupted dozens >> of times per second). > > Yes, it is the same here: 30ms on my notebook is not enough for WinTV > USB2 (it is OK with HVR-950). > >> Turned it up to 50ms and it's much better. >> That said, of course such a change would impact lipsync, so perhaps we >> need to be adjusting the periods instead. > > We've added a parameter for that on xawtv3 (--alsa-latency). We've > parametrized > it at the alsa stream function call. So, all it needs is to add a new > parameter > at tvtime config file. Ugh. We really need some sort of heuristic to do this. It's unreasonable to expect users to know about some magic parameter buried in a config file which causes it to start working. Perhaps a counter that increments whenever an underrun is hit, and after a certain number it automatically restarts the stream with a higher latency. Or perhaps we're just making some poor choice in terms of the buffers/periods for a given rate. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Em 07-09-2011 00:20, Devin Heitmueller escreveu:
> On Tue, Sep 6, 2011 at 10:58 PM, Devin Heitmueller
> wrote:
>> On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab
>> wrote:
>>> There are several issues with the original alsa_stream code that got
>>> fixed on xawtv3, made by me and by Hans de Goede. Basically, the
>>> code were re-written, in order to follow the alsa best practises.
>>>
>>> Backport the changes from xawtv, in order to make it to work on a
>>> wider range of V4L and sound adapters.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab
>>
>> Mauro,
>>
>> What tuners did you test this patch with? I went ahead and did a git
>> pull of your patch series into my local git tree, and now my DVC-90
>> (an em28xx device) is capturing at 32 KHz instead of 48 (this is one
>> of the snd-usb-audio based devices, not em28xx-alsa).
>>
>> Note I tested immediately before pulling your patch series and the
>> audio capture was working fine.
>>
>> I think this patch series is going in the right direction in general,
>> but this patch in particular seems to cause a regression. Is this
>> something you want to investigate? I think we need to hold off on
>> pulling this series into the new tvtime master until this problem is
>> resolved.
>>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> http://www.kernellabs.com
>>
>
> Spent a few minutes digging into this. Looks like the snd-usb-audio
> driver advertises 8-48KHz. However, it seems that it only captures
> successfully at 48 KHz.
>
> I made the following hack and it started working:
>
> diff --git a/src/alsa_stream.c b/src/alsa_stream.c
> index b6a41a5..57e3c3d 100644
> --- a/src/alsa_stream.c
> +++ b/src/alsa_stream.c
> @@ -261,7 +261,7 @@ static int setparams(snd_pcm_t *phandle, snd_pcm_t
> *chandle,
> fprintf(error_fp, "alsa: Will search a common rate between %u and
> %u\n",
> ratemin, ratemax);
>
> -for (i = ratemin; i <= ratemax; i+= 100) {
> +for (i = ratemax; i >= ratemin; i-= 100) {
> err = snd_pcm_hw_params_set_rate_near(chandle, c_hwparams, &i, 0);
> if (err)
> continue;
>
> Basically the above starts at the *maximum* capture resolution and
> works its way down. One might argue that this heuristic makes more
> sense anyway - why *wouldn't* you want the highest quality audio
> possible by default (rather than the lowest)?
That change makes sense to me. Yet, you should try to disable pulseaudio
and see what's the _real_ speed that the audio announces. On Fedora,
just removing pulsaudio-oss-plugin (or something like that) is enough.
It seems doubtful that my em2820 WinTV USB2 is different than yours.
I suspect that pulseaudio is passing the "extra" range, offering to
interpolate the data.
> Even with that patch though, I hit severe underrun/overrun conditions
> at 30ms of latency (to the point where the audio is interrupted dozens
> of times per second).
Yes, it is the same here: 30ms on my notebook is not enough for WinTV
USB2 (it is OK with HVR-950).
> Turned it up to 50ms and it's much better.
> That said, of course such a change would impact lipsync, so perhaps we
> need to be adjusting the periods instead.
We've added a parameter for that on xawtv3 (--alsa-latency). We've parametrized
it at the alsa stream function call. So, all it needs is to add a new parameter
at tvtime config file.
> ALSA has never been my area of expertise, so I look to you and Hans to
> offer some suggestions.
>
> Devin
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Em 06-09-2011 23:58, Devin Heitmueller escreveu: > On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab > wrote: >> There are several issues with the original alsa_stream code that >> got fixed on xawtv3, made by me and by Hans de Goede. Basically, >> the code were re-written, in order to follow the alsa best >> practises. >> >> Backport the changes from xawtv, in order to make it to work on a >> wider range of V4L and sound adapters. >> >> Signed-off-by: Mauro Carvalho Chehab > > Mauro, > > What tuners did you test this patch with? I tested with some em28xx-based devices, like HVR-950 and WinTV USB2. > I went ahead and did a git pull of your patch series into my local > git tree, and now my DVC-90 (an em28xx device) is capturing at 32 KHz > instead of 48 (this is one of the snd-usb-audio based devices, not > em28xx-alsa). The new approach tries to match an speed that it is compatible between the audio and the video card. The algorithm tries first to not use software interpolation for audio, as it would reduce the audio quality. If it can't do it without interpolation, it will enable interpolation and seek again. By default, pulseaudio does interpolation, if you request it to use a different resolution. > Note I tested immediately before pulling your patch series and the > audio capture was working fine. Had you test to disable pulseaudio and see what speeds your boards accept? If you enable verbose mode, you'll see more details about the device detection. For example, this is what I get here with hvr-950, calling "tvtime -v": alsa: starting copying alsa stream from hw:1,0 to hw:0,0 videoinput: Using video4linux2 driver 'em28xx', card 'Hauppauge WinTV HVR 950' (bus usb-:00:1d.7-1). videoinput: Version is 196608, capabilities 5030051. alsa: Capture min rate is 48000 alsa: Capture max rate is 48000 alsa: Playback min rate is 44100 alsa: Playback max rate is 192000 alsa: Will search a common rate between 48000 and 48000 alsa: Using Rate 48000 alsa: capture periods range between 2 and 98. Want: 2 alsa: capture period time range between 333 and 65334. Want: 15000 alsa: playback periods range between 2 and 32. Want: 4 alsa: playback period time range between 666 and 10922667. Want: 15000 alsa: capture period set to 2 periods of 15000 time alsa: playback period set to 4 periods of 15333 time alsa: Negociated configuration: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 2944 period_size : 736 period_time : 15333 tstamp_mode : NONE period_step : 1 avail_min: 736 period_event : 0 start_threshold : 1440 stop_threshold : 2944 silence_threshold: 0 silence_size : 0 boundary : 1543503872 stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 1440 period_size : 720 period_time : 15000 tstamp_mode : NONE period_step : 1 avail_min: 720 period_event : 0 start_threshold : 720 stop_threshold : 1440 silence_threshold: 0 silence_size : 0 boundary : 1509949440 alsa: Parameters are 48000Hz, S16_LE, 2 channels alsa: Set bitrate to 48000, buffer size is 1440 alsa: stream started from hw:1,0 to hw:0,0 (48000 Hz, buffer delay = 30,00 ms) And those are the results with WinTV USB2: videoinput: Using video4linux2 driver 'em28xx', card 'Hauppauge WinTV USB 2' (bus usb-:00:1d.7-1). videoinput: Version is 196608, capabilities 5030041. alsa: starting copying alsa stream from hw:1,0 to hw:0,0 alsa: Capture min rate is 32000 alsa: Capture max rate is 32000 alsa: Playback min rate is 44100 alsa: Playback max rate is 192000 alsa: Will search a common rate between 44100 and 32000 alsa: Couldn't find a rate that it is supported by both playback and capture alsa: Trying plughw:0,0 for playback alsa: Resample enabled. alsa: Capture min rate is 32000 alsa: Capture max rate is 32000 alsa: Playback min rate is 4000 alsa: Playback max rate is 4294967295 alsa: Will search a common rate between 32000 and 32000 alsa: Using Rate 32000 alsa: capture periods range between 2 and 1024. Want: 2 alsa: capture period time range between 500 and 4096000. Want: 15000 alsa: playback period time range between 333 and 5461334. Want: 15000 alsa: capture period set to 2 periods of 15000 time alsa: playback period set to 4 periods of 15000 time alsa: Negociated configuration: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 32000 exact rate : 32000 (32000/1) msbits : 16 buffer_size : 1920 period_size : 480 period_time : 15000 tstamp_mode : NONE period_step : 1 avail_min: 480 period_event : 0 start_threshold : 960 stop_
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 10:58 PM, Devin Heitmueller
wrote:
> On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab
> wrote:
>> There are several issues with the original alsa_stream code that got
>> fixed on xawtv3, made by me and by Hans de Goede. Basically, the
>> code were re-written, in order to follow the alsa best practises.
>>
>> Backport the changes from xawtv, in order to make it to work on a
>> wider range of V4L and sound adapters.
>>
>> Signed-off-by: Mauro Carvalho Chehab
>
> Mauro,
>
> What tuners did you test this patch with? I went ahead and did a git
> pull of your patch series into my local git tree, and now my DVC-90
> (an em28xx device) is capturing at 32 KHz instead of 48 (this is one
> of the snd-usb-audio based devices, not em28xx-alsa).
>
> Note I tested immediately before pulling your patch series and the
> audio capture was working fine.
>
> I think this patch series is going in the right direction in general,
> but this patch in particular seems to cause a regression. Is this
> something you want to investigate? I think we need to hold off on
> pulling this series into the new tvtime master until this problem is
> resolved.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
Spent a few minutes digging into this. Looks like the snd-usb-audio
driver advertises 8-48KHz. However, it seems that it only captures
successfully at 48 KHz.
I made the following hack and it started working:
diff --git a/src/alsa_stream.c b/src/alsa_stream.c
index b6a41a5..57e3c3d 100644
--- a/src/alsa_stream.c
+++ b/src/alsa_stream.c
@@ -261,7 +261,7 @@ static int setparams(snd_pcm_t *phandle, snd_pcm_t *chandle,
fprintf(error_fp, "alsa: Will search a common rate between %u and %u\n",
ratemin, ratemax);
-for (i = ratemin; i <= ratemax; i+= 100) {
+for (i = ratemax; i >= ratemin; i-= 100) {
err = snd_pcm_hw_params_set_rate_near(chandle, c_hwparams, &i, 0);
if (err)
continue;
Basically the above starts at the *maximum* capture resolution and
works its way down. One might argue that this heuristic makes more
sense anyway - why *wouldn't* you want the highest quality audio
possible by default (rather than the lowest)?
Even with that patch though, I hit severe underrun/overrun conditions
at 30ms of latency (to the point where the audio is interrupted dozens
of times per second). Turned it up to 50ms and it's much better.
That said, of course such a change would impact lipsync, so perhaps we
need to be adjusting the periods instead.
ALSA has never been my area of expertise, so I look to you and Hans to
offer some suggestions.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab wrote: > There are several issues with the original alsa_stream code that got > fixed on xawtv3, made by me and by Hans de Goede. Basically, the > code were re-written, in order to follow the alsa best practises. > > Backport the changes from xawtv, in order to make it to work on a > wider range of V4L and sound adapters. > > Signed-off-by: Mauro Carvalho Chehab Mauro, What tuners did you test this patch with? I went ahead and did a git pull of your patch series into my local git tree, and now my DVC-90 (an em28xx device) is capturing at 32 KHz instead of 48 (this is one of the snd-usb-audio based devices, not em28xx-alsa). Note I tested immediately before pulling your patch series and the audio capture was working fine. I think this patch series is going in the right direction in general, but this patch in particular seems to cause a regression. Is this something you want to investigate? I think we need to hold off on pulling this series into the new tvtime master until this problem is resolved. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Em 06-09-2011 18:18, Devin Heitmueller escreveu: > On Tue, Sep 6, 2011 at 3:12 PM, Mauro Carvalho Chehab > wrote: >>> From a practical standpoint, the Ubuntu folks have the original tvtime >>> tarball and all their changes in one patch, which is clearly a bunch >>> of patches that are mashed together probably in their build system. I >>> need to reach out to them to find where they have an actual SCM tree >>> or the individual patches. They've got a bunch of patches which would >>> be good to get into a single tree (autobuild fixes, cross-compilation, >>> locale updates, etc). >> >> Yeah, it seems interesting. Maybe we can get something from this place: >>http://packages.qa.debian.org/t/tvtime.html >> >> The maintainer there seems to be: >>http://qa.debian.org/developer.php?login=ba...@debian.org > > I reached out to the Ubuntu maintainer; we'll see if he gets back to > me. From what I can tell it seems like Debian is actually taking the > patches from Ubuntu (yes, I realize this is backwards from their > typical process where Ubuntu bases their stuff on Debian). Good! >>> In the long term I have no real issue with the LinuxTV group being the >>> official maintainer of record. I've got lots of ideas and things I >>> would like to do to improve tvtime, but in practice I've done a pretty >>> crappy job of maintaining the source (merging patches, etc) at this >>> point. >> >> Putting it on a common place and giving permissions to a group of people >> is interesting, as none of us are focused on userspace, so we all >> have a very limited amount of time for dealing with userspace applications. >> >> By giving commit rights to a group of developers, it ends that more >> developers will contribute, speeding up the development. >> >> That was what happened with v4l-utils and, on a minor scale, with xawtv3. >> >> If you're ok with that, I can set a tvtime git repository at LinuxTV, >> cloning the tree I've created there already (it is a pure conversion >> of your tree from mercurial into git, if I remove the patches I've >> done so far from your clone), giving you the ownership of the new tree, >> and marking it as a shared repository. > > I have no problem with this. Let's set it up. Ok. The repository is here: http://git.linuxtv.org/tvtime.git In thesis, everything is set for group usage. Please let me know if you experience any troubles with it. >> I have already all set there to allow shared access to the repository >> (in opposite to -hg, git works really cool with shared repositories). > > I actually haven't hosted any git repos on linuxtv.org before. I'm > assuming my ssh public key got copied over from when I was hosting hg > repos there? The same key is used, whatever you're committing to cvs, hg or git. The maintenance application for git is called git-menu. >> We can later add permissions to the developers interested on helping >> the tvtime maintenance that you agree to add. > > Sounds good. >From my side, I'm interested on helping with it. When I have some time, I'd like to fix a few issues with it. For example, there's a local cable operator that broadcasts some channels with PAL/M and others with NTSC/M (not a big deal for STBs and TV sets, as almost all support both standards here). However, tvtime, needs to be restarted every time it changes from one to the other, and it is not possible to set a per-channel standard. To be worse, when tvtime is restarted, it doesn't honor the "-d" option, with means that it will open my laptop's webcam instead of the TV card. > > As said earlier, Kernel Labs never really wanted to be the maintainer > for tvtime - we did it because nobody else wanted to (and vektor never > responded to emails I sent him offering to help). That said, a > community oriented approach is probably the best for everybody > involved. > > I'll probably be looking in the next couple of weeks to write some > fresh content for a tvtime website. The stuff on > tvtime.sourceforge.net is so dated almost none of it still applies. Yeah, that makes sense. > Thanks, > > Devin > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 3:12 PM, Mauro Carvalho Chehab wrote: >> From a practical standpoint, the Ubuntu folks have the original tvtime >> tarball and all their changes in one patch, which is clearly a bunch >> of patches that are mashed together probably in their build system. I >> need to reach out to them to find where they have an actual SCM tree >> or the individual patches. They've got a bunch of patches which would >> be good to get into a single tree (autobuild fixes, cross-compilation, >> locale updates, etc). > > Yeah, it seems interesting. Maybe we can get something from this place: > http://packages.qa.debian.org/t/tvtime.html > > The maintainer there seems to be: > http://qa.debian.org/developer.php?login=ba...@debian.org I reached out to the Ubuntu maintainer; we'll see if he gets back to me. From what I can tell it seems like Debian is actually taking the patches from Ubuntu (yes, I realize this is backwards from their typical process where Ubuntu bases their stuff on Debian). >> In the long term I have no real issue with the LinuxTV group being the >> official maintainer of record. I've got lots of ideas and things I >> would like to do to improve tvtime, but in practice I've done a pretty >> crappy job of maintaining the source (merging patches, etc) at this >> point. > > Putting it on a common place and giving permissions to a group of people > is interesting, as none of us are focused on userspace, so we all > have a very limited amount of time for dealing with userspace applications. > > By giving commit rights to a group of developers, it ends that more > developers will contribute, speeding up the development. > > That was what happened with v4l-utils and, on a minor scale, with xawtv3. > > If you're ok with that, I can set a tvtime git repository at LinuxTV, > cloning the tree I've created there already (it is a pure conversion > of your tree from mercurial into git, if I remove the patches I've > done so far from your clone), giving you the ownership of the new tree, > and marking it as a shared repository. I have no problem with this. Let's set it up. > I have already all set there to allow shared access to the repository > (in opposite to -hg, git works really cool with shared repositories). I actually haven't hosted any git repos on linuxtv.org before. I'm assuming my ssh public key got copied over from when I was hosting hg repos there? > We can later add permissions to the developers interested on helping > the tvtime maintenance that you agree to add. Sounds good. As said earlier, Kernel Labs never really wanted to be the maintainer for tvtime - we did it because nobody else wanted to (and vektor never responded to emails I sent him offering to help). That said, a community oriented approach is probably the best for everybody involved. I'll probably be looking in the next couple of weeks to write some fresh content for a tvtime website. The stuff on tvtime.sourceforge.net is so dated almost none of it still applies. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Em 06-09-2011 15:41, Devin Heitmueller escreveu: > On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede wrote: >> I think that what should be done is contact the debian / ubuntu maintainers, >> get any interesting fixes they have which the kl version misses merged, >> and then just declare the kl version as being the new official upstream >> (with the blessing of the debian / ubuntu guys, and if possible also >> with the blessing of the original authors). > > It has always been my intention to get the Debian/Ubuntu patches > merged (as well as other distros). My thoughts behind renaming were > oriented around the notion that that there are more distros out there > than just Fedora/Ubuntu/Debian, but that may be something that isn't > really a concern. Also, I had no idea whether the distros would > actually switch over to the Kernel Labs version as the official > upstream source, so providing it under a different name would in > theory allow both packages to be available in parallel. > > From a practical standpoint, the Ubuntu folks have the original tvtime > tarball and all their changes in one patch, which is clearly a bunch > of patches that are mashed together probably in their build system. I > need to reach out to them to find where they have an actual SCM tree > or the individual patches. They've got a bunch of patches which would > be good to get into a single tree (autobuild fixes, cross-compilation, > locale updates, etc). Yeah, it seems interesting. Maybe we can get something from this place: http://packages.qa.debian.org/t/tvtime.html The maintainer there seems to be: http://qa.debian.org/developer.php?login=ba...@debian.org >> This would require kl git to be open to others for pushing, or we >> could move the tree to git.linuxtv.org (which I assume may be >> easier then for you to make the necessary changes to give >> others push rights on kl.org). > > Kernel Labs has never really had any real interest in "owning" tvtime. > I just setup the hg tree in an effort to get all the distro patches > in one place and have something that builds against current kernels > (and on which I can add improvements/fixes without users having to > deal with patches). At the time there was also nobody who clearly had > the desire to serve as an official maintainer. > > In the long term I have no real issue with the LinuxTV group being the > official maintainer of record. I've got lots of ideas and things I > would like to do to improve tvtime, but in practice I've done a pretty > crappy job of maintaining the source (merging patches, etc) at this > point. Putting it on a common place and giving permissions to a group of people is interesting, as none of us are focused on userspace, so we all have a very limited amount of time for dealing with userspace applications. By giving commit rights to a group of developers, it ends that more developers will contribute, speeding up the development. That was what happened with v4l-utils and, on a minor scale, with xawtv3. If you're ok with that, I can set a tvtime git repository at LinuxTV, cloning the tree I've created there already (it is a pure conversion of your tree from mercurial into git, if I remove the patches I've done so far from your clone), giving you the ownership of the new tree, and marking it as a shared repository. I have already all set there to allow shared access to the repository (in opposite to -hg, git works really cool with shared repositories). We can later add permissions to the developers interested on helping the tvtime maintenance that you agree to add. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 2:43 PM, Hans de Goede wrote: > Hi, > > On 09/06/2011 08:35 PM, Michael Krufky wrote: >> >> On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 09/06/2011 06:24 PM, Devin Heitmueller wrote: >>> >>> >>> I've been thinking for a while that perhaps the project should be renamed (or I considered prepending "kl" onto the front resulting in it being called "kl-tvtime"). This isn't out of vanity but rather my concern that the fork will get confused with the original project (for example, I believe Ubuntu actually already calls their modified tree tvtime 1.0.3). I'm open to suggestions in this regards. >>> >>> I think that what should be done is contact the debian / ubuntu >>> maintainers, >>> get any interesting fixes they have which the kl version misses merged, >>> and then just declare the kl version as being the new official upstream >>> (with the blessing of the debian / ubuntu guys, and if possible also >>> with the blessing of the original authors). >>> >>> This would require kl git to be open to others for pushing, or we >>> could move the tree to git.linuxtv.org (which I assume may be >>> easier then for you to make the necessary changes to give >>> others push rights on kl.org). >> >> Hans, >> >> Everybody is welcome to contribute to open source projects, but global >> contribution doesn't mean that a given server be opened up to commits >> by the general public. > > I didn't write open to commits by the general public, now did I? I wrote > open to commits by others. For most upstream projects it is quite normal > that several people have push rights to the master tree. This actually > is quite a good idea, as it avoids adding a SPOF into the chain. It > means development can continue if one of the maintainers is on vacation > for a a few weeks, or just having a period in his/her life where he > is too busy to actively contribute to a spare time project. Hans, Now I understand -- that's completely reasonable. It looks like Devin is happy having the tree hosted on linuxtv.org anyway, so no worries :-) Sorry for the misunderstanding. Best Regards, Mike Krufky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Hi, On 09/06/2011 08:35 PM, Michael Krufky wrote: On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede wrote: Hi, On 09/06/2011 06:24 PM, Devin Heitmueller wrote: I've been thinking for a while that perhaps the project should be renamed (or I considered prepending "kl" onto the front resulting in it being called "kl-tvtime"). This isn't out of vanity but rather my concern that the fork will get confused with the original project (for example, I believe Ubuntu actually already calls their modified tree tvtime 1.0.3). I'm open to suggestions in this regards. I think that what should be done is contact the debian / ubuntu maintainers, get any interesting fixes they have which the kl version misses merged, and then just declare the kl version as being the new official upstream (with the blessing of the debian / ubuntu guys, and if possible also with the blessing of the original authors). This would require kl git to be open to others for pushing, or we could move the tree to git.linuxtv.org (which I assume may be easier then for you to make the necessary changes to give others push rights on kl.org). Hans, Everybody is welcome to contribute to open source projects, but global contribution doesn't mean that a given server be opened up to commits by the general public. I didn't write open to commits by the general public, now did I? I wrote open to commits by others. For most upstream projects it is quite normal that several people have push rights to the master tree. This actually is quite a good idea, as it avoids adding a SPOF into the chain. It means development can continue if one of the maintainers is on vacation for a a few weeks, or just having a period in his/her life where he is too busy to actively contribute to a spare time project. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede wrote: > I think that what should be done is contact the debian / ubuntu maintainers, > get any interesting fixes they have which the kl version misses merged, > and then just declare the kl version as being the new official upstream > (with the blessing of the debian / ubuntu guys, and if possible also > with the blessing of the original authors). It has always been my intention to get the Debian/Ubuntu patches merged (as well as other distros). My thoughts behind renaming were oriented around the notion that that there are more distros out there than just Fedora/Ubuntu/Debian, but that may be something that isn't really a concern. Also, I had no idea whether the distros would actually switch over to the Kernel Labs version as the official upstream source, so providing it under a different name would in theory allow both packages to be available in parallel. >From a practical standpoint, the Ubuntu folks have the original tvtime tarball and all their changes in one patch, which is clearly a bunch of patches that are mashed together probably in their build system. I need to reach out to them to find where they have an actual SCM tree or the individual patches. They've got a bunch of patches which would be good to get into a single tree (autobuild fixes, cross-compilation, locale updates, etc). > This would require kl git to be open to others for pushing, or we > could move the tree to git.linuxtv.org (which I assume may be > easier then for you to make the necessary changes to give > others push rights on kl.org). Kernel Labs has never really had any real interest in "owning" tvtime. I just setup the hg tree in an effort to get all the distro patches in one place and have something that builds against current kernels (and on which I can add improvements/fixes without users having to deal with patches). At the time there was also nobody who clearly had the desire to serve as an official maintainer. In the long term I have no real issue with the LinuxTV group being the official maintainer of record. I've got lots of ideas and things I would like to do to improve tvtime, but in practice I've done a pretty crappy job of maintaining the source (merging patches, etc) at this point. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Em 06-09-2011 13:24, Devin Heitmueller escreveu: > On Tue, Sep 6, 2011 at 11:40 AM, Mauro Carvalho Chehab > wrote: >> Hi Devin, >> >> Em 06-09-2011 12:29, Mauro Carvalho Chehab escreveu: >>> There are several issues with the original alsa_stream code that got >>> fixed on xawtv3, made by me and by Hans de Goede. Basically, the >>> code were re-written, in order to follow the alsa best practises. >>> >>> Backport the changes from xawtv, in order to make it to work on a >>> wider range of V4L and sound adapters. >> >> FYI, just flooded your mailbox with 10 patches for tvtime. ;) >> >> I'm wanting to test some things with tvtime on one of my testboxes, but some >> of my cards weren't working with the alsa streaming, due to a few bugs that >> were solved on xawtv fork. >> >> So, I decided to backport it to tvtime and recompile the Fedora package for >> it. >> That's where the other 9 patches come ;) >> >> Basically, after applying this series of 10 patches, we can just remove all >> patches from Fedora, making life easier for distro maintainers (as the same >> thing is probably true on other distros - at least one of the Fedora patches >> came from Debian, from the fedora git logs). >> >> One important thing for distros is to have a tarball with the latest version >> hosted on a public site, so I've increased the version to 1.0.3 and I'm >> thinking on storing a copy of it at linuxtv, just like we do with xawtv3. >> >> If you prefer, all patches are also on my tvtime git tree, at: >> http://git.linuxtv.org/mchehab/tvtime.git >> >> Thanks, >> Mauro > > Hi Mauro, > > Funny you should send these along today. Last Friday I was actually > poking around at the Fedora tvtime repo because I was curious how they > had dealt with the V4L1 support issue (whether they were using my > patch removing v4l1 or some variant). Well, right time then ;) > > I've actually pulled in Fedora patches in the past (as you can see > from the hg repo), Yes, I saw it. Nice work! > and it has always been my intention to do it for > the other distros as well (e.g. debian/Ubuntu). So I appreciate your > having sent these along. It is a good idea to take a look at them. I looked into their repositories for the xawtv patches and I found some good stuff there. > I'll pull these in this week, do some testing to make sure nothing > serious got broken, and work to spin a 1.0.3 toward the end of the > week. Great! > Given the number of features/changes, and how long it's been > since the last formal release, I was considering calling it 1.1.0 > instead though. Seems fine for me. > I've been thinking for a while that perhaps the project should be > renamed (or I considered prepending "kl" onto the front resulting in > it being called "kl-tvtime"). This isn't out of vanity but rather my > concern that the fork will get confused with the original project (for > example, I believe Ubuntu actually already calls their modified tree > tvtime 1.0.3). I'm open to suggestions in this regards. IMO, I won't rename it. It is a well-known tool, and it is not a new version, but somebody's else took over its maintainership. I think you should touch the readme files in order to point to kl.com and to the places where the tree will be stored. Em 06-09-2011 15:19, Hans de Goede escreveu: > Hi, > I think that what should be done is contact the debian / ubuntu maintainers, > get any interesting fixes they have which the kl version misses merged, > and then just declare the kl version as being the new official upstream > (with the blessing of the debian / ubuntu guys, and if possible also > with the blessing of the original authors). Agree. I think Devin already tried to contact vektor about that. > This would require kl git to be open to others for pushing, or we > could move the tree to git.linuxtv.org (which I assume may be > easier then for you to make the necessary changes to give > others push rights on kl.org). I like this idea too. From my side, it proved to be very useful to be able to write on both Fedora and upstream repositories on xawtv3. I've made already the Fedora changes for tvtime 1.0.3 (in order to test it on my test boxes), so being able of adding a new release at both repos at the same time is a good idea. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede wrote: > Hi, > > On 09/06/2011 06:24 PM, Devin Heitmueller wrote: > > > >> I've been thinking for a while that perhaps the project should be >> renamed (or I considered prepending "kl" onto the front resulting in >> it being called "kl-tvtime"). This isn't out of vanity but rather my >> concern that the fork will get confused with the original project (for >> example, I believe Ubuntu actually already calls their modified tree >> tvtime 1.0.3). I'm open to suggestions in this regards. > > I think that what should be done is contact the debian / ubuntu maintainers, > get any interesting fixes they have which the kl version misses merged, > and then just declare the kl version as being the new official upstream > (with the blessing of the debian / ubuntu guys, and if possible also > with the blessing of the original authors). > > This would require kl git to be open to others for pushing, or we > could move the tree to git.linuxtv.org (which I assume may be > easier then for you to make the necessary changes to give > others push rights on kl.org). Hans, Everybody is welcome to contribute to open source projects, but global contribution doesn't mean that a given server be opened up to commits by the general public. You should feel free to push to your own git tree hosted on linuxtv.org (or any public git server, for that matter) and send pull requests to Devin Heitmueller, who is currently maintaining the kernellabs version of tvtime. Regards, Michael Krufky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Hi, On 09/06/2011 06:24 PM, Devin Heitmueller wrote: I've been thinking for a while that perhaps the project should be renamed (or I considered prepending "kl" onto the front resulting in it being called "kl-tvtime"). This isn't out of vanity but rather my concern that the fork will get confused with the original project (for example, I believe Ubuntu actually already calls their modified tree tvtime 1.0.3). I'm open to suggestions in this regards. I think that what should be done is contact the debian / ubuntu maintainers, get any interesting fixes they have which the kl version misses merged, and then just declare the kl version as being the new official upstream (with the blessing of the debian / ubuntu guys, and if possible also with the blessing of the original authors). This would require kl git to be open to others for pushing, or we could move the tree to git.linuxtv.org (which I assume may be easier then for you to make the necessary changes to give others push rights on kl.org). Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:40 AM, Mauro Carvalho Chehab wrote: > Hi Devin, > > Em 06-09-2011 12:29, Mauro Carvalho Chehab escreveu: >> There are several issues with the original alsa_stream code that got >> fixed on xawtv3, made by me and by Hans de Goede. Basically, the >> code were re-written, in order to follow the alsa best practises. >> >> Backport the changes from xawtv, in order to make it to work on a >> wider range of V4L and sound adapters. > > FYI, just flooded your mailbox with 10 patches for tvtime. ;) > > I'm wanting to test some things with tvtime on one of my testboxes, but some > of my cards weren't working with the alsa streaming, due to a few bugs that > were solved on xawtv fork. > > So, I decided to backport it to tvtime and recompile the Fedora package for > it. > That's where the other 9 patches come ;) > > Basically, after applying this series of 10 patches, we can just remove all > patches from Fedora, making life easier for distro maintainers (as the same > thing is probably true on other distros - at least one of the Fedora patches > came from Debian, from the fedora git logs). > > One important thing for distros is to have a tarball with the latest version > hosted on a public site, so I've increased the version to 1.0.3 and I'm > thinking on storing a copy of it at linuxtv, just like we do with xawtv3. > > If you prefer, all patches are also on my tvtime git tree, at: > http://git.linuxtv.org/mchehab/tvtime.git > > Thanks, > Mauro Hi Mauro, Funny you should send these along today. Last Friday I was actually poking around at the Fedora tvtime repo because I was curious how they had dealt with the V4L1 support issue (whether they were using my patch removing v4l1 or some variant). I've actually pulled in Fedora patches in the past (as you can see from the hg repo), and it has always been my intention to do it for the other distros as well (e.g. debian/Ubuntu). So I appreciate your having sent these along. I'll pull these in this week, do some testing to make sure nothing serious got broken, and work to spin a 1.0.3 toward the end of the week. Given the number of features/changes, and how long it's been since the last formal release, I was considering calling it 1.1.0 instead though. I've been thinking for a while that perhaps the project should be renamed (or I considered prepending "kl" onto the front resulting in it being called "kl-tvtime"). This isn't out of vanity but rather my concern that the fork will get confused with the original project (for example, I believe Ubuntu actually already calls their modified tree tvtime 1.0.3). I'm open to suggestions in this regards. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
Hi Devin,
Em 06-09-2011 12:29, Mauro Carvalho Chehab escreveu:
> There are several issues with the original alsa_stream code that got
> fixed on xawtv3, made by me and by Hans de Goede. Basically, the
> code were re-written, in order to follow the alsa best practises.
>
> Backport the changes from xawtv, in order to make it to work on a
> wider range of V4L and sound adapters.
FYI, just flooded your mailbox with 10 patches for tvtime. ;)
I'm wanting to test some things with tvtime on one of my testboxes, but some
of my cards weren't working with the alsa streaming, due to a few bugs that
were solved on xawtv fork.
So, I decided to backport it to tvtime and recompile the Fedora package for it.
That's where the other 9 patches come ;)
Basically, after applying this series of 10 patches, we can just remove all
patches from Fedora, making life easier for distro maintainers (as the same
thing is probably true on other distros - at least one of the Fedora patches
came from Debian, from the fedora git logs).
One important thing for distros is to have a tarball with the latest version
hosted on a public site, so I've increased the version to 1.0.3 and I'm
thinking on storing a copy of it at linuxtv, just like we do with xawtv3.
If you prefer, all patches are also on my tvtime git tree, at:
http://git.linuxtv.org/mchehab/tvtime.git
Thanks,
Mauro
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> src/alsa_stream.c | 629
> ++---
> src/alsa_stream.h |6 +-
> src/tvtime.c |6 +-
> 3 files changed, 363 insertions(+), 278 deletions(-)
>
> diff --git a/src/alsa_stream.c b/src/alsa_stream.c
> index 2243b02..b6a41a5 100644
> --- a/src/alsa_stream.c
> +++ b/src/alsa_stream.c
> @@ -6,6 +6,9 @@
>* Derived from the alsa-driver test tool latency.c:
>*Copyright (c) by Jaroslav Kysela
>*
> + * Copyright (c) 2011 - Mauro Carvalho Chehab
> + * Ported to xawtv, with bug fixes and improvements
> + *
>* This program is free software; you can redistribute it and/or modify
>* it under the terms of the GNU General Public License as published by
>* the Free Software Foundation; either version 2 of the License, or
> @@ -32,8 +35,16 @@
> #include
> #include
> #include
> +#include "alsa_stream.h"
> +
> +/* Private vars to control alsa thread status */
> +static int alsa_is_running = 0;
> +static int stop_alsa = 0;
>
> +/* Error handlers */
> snd_output_t *output = NULL;
> +FILE *error_fp;
> +int verbose = 0;
>
> struct final_params {
> int bufsize;
> @@ -42,403 +53,435 @@ struct final_params {
> int channels;
> };
>
> -int setparams_stream(snd_pcm_t *handle,
> - snd_pcm_hw_params_t *params,
> - snd_pcm_format_t format,
> - int channels,
> - int rate,
> - const char *id)
> +static int setparams_stream(snd_pcm_t *handle,
> + snd_pcm_hw_params_t *params,
> + snd_pcm_format_t format,
> + int channels,
> + const char *id)
> {
> int err;
> -unsigned int rrate;
>
> err = snd_pcm_hw_params_any(handle, params);
> if (err< 0) {
> - printf("Broken configuration for %s PCM: no configurations available:
> %s\n", snd_strerror(err), id);
> - return err;
> -}
> -err = snd_pcm_hw_params_set_rate_resample(handle, params, 1);
> -if (err< 0) {
> - printf("Resample setup failed for %s: %s\n", id, snd_strerror(err));
> + fprintf(error_fp,
> + "alsa: Broken configuration for %s PCM: no configurations
> available: %s\n",
> + snd_strerror(err), id);
> return err;
> }
> +
> err = snd_pcm_hw_params_set_access(handle, params,
> SND_PCM_ACCESS_RW_INTERLEAVED);
> if (err< 0) {
> - printf("Access type not available for %s: %s\n", id,
> -snd_strerror(err));
> + fprintf(error_fp, "alsa: Access type not available for %s: %s\n", id,
> + snd_strerror(err));
> return err;
> }
>
> err = snd_pcm_hw_params_set_format(handle, params, format);
> if (err< 0) {
> - printf("Sample format not available for %s: %s\n", id,
> + fprintf(error_fp, "alsa: Sample format not available for %s: %s\n", id,
> snd_strerror(err));
> return err;
> }
> err = snd_pcm_hw_params_set_channels(handle, params, channels);
> if (err< 0) {
> - printf("Channels count (%i) not available for %s: %s\n", channels, id,
> -snd_strerror(err));
> - return err;
> -}
> -rrate = rate;
> -err = snd_pcm_hw_params_set_rate_near(handle, params,&rrate, 0);
> -if (err< 0) {
> - printf("Rate %iHz not available for %s: %s\n", rate, id,
> -snd_strerror(err));
> + fprintf(error_fp, "alsa: Channels count (%i) not
