got it too in bug #161704 but this pipeline is working for me

gstalsa.c(1491):gst_alsa_probe_hw_params:<alsasink0>
"snd_pcm_hw_params_set_period_size_near (this->handle, hw_params, &period_size,
0)": Argument invalide

= Invalid Argument

try to change your audiosink to "alsasink device=plughw:0"
in gstreamer-properties

Doesn't work for me :(

You didn't mention what sound hardware/driver you are using. I have a card with  
YMF754 and use the ymfpci driver, and the pipeline mentioned fails with the 
same error if I don't supply "period-count=n" where n is 3 or more to alsasink. 
The ymfpci driver requires at least three periods for some reason, and alsasink 
tries to use 2 by default. You can try different values and see what happens, 
or you may look at your alsa driver sources for your card and search for 
periods_min. 
 

yes it's a card with the ymfpci driver
0000:00:0b.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S
Audio Controller] (rev 02)

adding period-count=2 works for me... thanks :) can this somehow be set standard?

bye

sorry... meant period-count=3

i suppose it is some more HW capability testing we don't do.

alsa provides those functions :

  err = snd_pcm_hw_params_get_buffer_size_min(params, &buffer_size_min);
  err = snd_pcm_hw_params_get_buffer_size_max(params, &buffer_size_max);
  err = snd_pcm_hw_params_get_period_size_min(params, &period_size_min,&dir);
  err = snd_pcm_hw_params_get_period_size_max(params, &period_size_max,&dir);

to probe supported buffer_size/period_size min and max. but in alsasink, they
are fixed.

well, for this specific bug, the following 2 should be used :

 int snd_pcm_hw_params_get_periods_min/max

i'll try to add the 3(buffer_size/period_size/period_count)x2(min/max) checks
before next release

Created attachment 35769 [details] [review]
min/max period_count probing. should fix default if <min or > max

please test it

seems to work for me :
hw:0	 from 1 to 1024 (real device)
plughw:0 from 0 to 4294967295 (software device)

i'll apply it in CVS once you report me (good) results.

then i'll do the same for period_size and buffer_size

Created attachment 35774 [details] [review]
mix/max probing for period_count/period_size/buffer_size

it is a verbose version (remove the printf lines to have a silent one)

a(period_count), b(period_size), c(buffer_size)
1(before any probe), 2(after MIN probe), 3(after MAX probe), 4(final values)

applying non-verbose version to CVS now (shouldn't hurt)

if the bug is still present after this patch, it could be your driver that does
not report its capabilities properly

With the last patch I get the following output... seems the ymfpci driver
reports something wrong...

gst-launch-0.8 --gst-debug-level=2 sinesrc ! audioconvert ! audioscale ! alsasink
RUNNING pipeline ...
a1 : min=2, max=64, current=2
a2 : min=0, max=64, current=2
a3 : min=2, max=204522253, current=2
a4 : min=2, max=64, current=2
b1 : min=2, max=8192, current=8192
b2 : min=21, max=8192, current=8192
b3 : min=22, max=4294967295, current=8192
b4 : min=22, max=8192, current=8192
c1 : min=4, max=65536, current=16384
c2 : min=10, max=65536, current=16384
c3 : min=10, max=4294967294, current=16384
c4 : min=10, max=65536, current=16384
WARN  (0x80508e8 - 307045:31:21.122260000)            alsa( 2455)
gstalsa.c(1592):gst_alsa_probe_hw_params:<alsasink0>
"snd_pcm_hw_params_set_periods_near (this->handle, hw_params, &period_count,
0)": Das Argument ist ungültig
ERROR: pipeline doesn't want to play.

yep, it reports  :

period_count : MIN= 0 & MAX=204522253
period_size  : MIN=22 & MAX=4294967295
buffer_size  : MIN=10 & MAX=4294967294

all values looks bad (i think period_count=0 is not valid for a real hardware
device)

those values look like the one i've got when using plughw:0 instead of hw:0

Gtreamer minimum period_count is 2, driver says its minimum is 0, so Gstreamer
chooses 2. unfortunatly, in use, your driver card won't accept a value under 3.

it looks like a driver/alsa bug. i should close this bug as NOTGNOME.

i'll let it open in case other people have the same problem (they'll be able to
find the workaround which is setting period_count to 3)

In this case, report a bug to the ALSA team.

already done

can you put here the link to the alsa bug
and put in the alsa bug the link to this page too ?

It's there: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=802

I have similar problem on a mb asus k8ne with a nforce3 runing debian sid

in mplayer alsa work but in gstreamer-propertie i got an error (failed to
construct pipiline...)

if i use oss it's work
i have tested workaround in this thread but still don't work
i have tested this (is it a good test in this case ?)
gst-launch-0.8 --gst-debug-level=2 sinesrc ! audioconvert ! audioscale ! alsasink

EXECUTION du tube en cours ...
WARN  (0x50ac80 - 307584:06:45.796562000)            alsa( 9061)
gstalsa.c(1491):gst_alsa_probe_hw_params:<alsasink0>
"snd_pcm_hw_params_set_period_size_near (this->handle, hw_params, &period_size,
0)": Argument invalide
ERREUR: le tube refuse de s'executer.

i tried with different period count (from 2 to 100) alsasink device=plughw:0 
period-count=100

EXECUTION du tube en cours ...
WARN  (0x50ac80 - 307584:06:11.721925000)            alsa( 9044)
gstalsa.c(1491):gst_alsa_probe_hw_params:<alsasink0>
"snd_pcm_hw_params_set_period_size_near (this->handle, hw_params, &period_size,
0)": Argument invalide
ERREUR: le tube refuse de s'executer.

versions
gstreamer0.8-alsa  0.8.7-3
alsa-base          1.0.8-4 
kernel             2.6.10

i got it working
It seem that alsa need /etc/asound.conf to work well

Benjamin added period-count "let the kernel figure it out" code too, now. That
should fix all remaining issues people were having. Please open specific new bug
reports for new issues with CVS of today or newer.