date:20170219

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Cinaed Simson


My guess is you have pulse audio installed but it won't let you use the
audio devices because you're not logged into the console on the pi3.

Type

  ps -ef | grep pulse

which should return entries similar to

  /usr/bin/pulseaudio --start --log-target=syslog
  /bin/sh /usr/bin/start-pulseaudio-x11

Note, if pulse-audio is the problem, then you need to log into the
console and change your audio device to 'pulse' before trying it again.

-- Cinaed


On 02/19/2017 12:17 PM, Robin A. Jensen wrote:
> Hello Marcus.
> 
> I've haven't copy  pasted!
> I made it from a tutorial and it will work on Window 10 machine. :-)
> 
> Now i have tried your suggestion and the RuntimeError is till persist.
> But you lost min the part, about moving the resampler in front of WBFM.
> I did it and the Runtime error is still presentet.
> 
> But i'm sure that there is a bug in the debian versin of GNU Radio
> Companion 3.7.5 when using Rationel Resampler.
> It's making no sense. I have understood the concept of Decimating and
> Interpolation.
> I now have done some test with exactly the same simple setup on Windows
> 10 and RPi 3 Jessie.
> On Windows:
> Souce: resample 480 k Waveform: Cosine, Freq: 1k->
> Rationel Resampler: Decimation 480 (= 1000), Interpolation 48 (=48.000) ->
> Audio Sink: Sample Rate: 48k
> 
> It will produce a tone of 1 KHz.
> 
> Doing precise the same on RPi 3:
> RuntimeError: audio_alsa_sink
> Only when Rationel Resampler is set to: Interpolation 48000,
> It will run, but if Decimation is 480 (= 1000 -> 1000 * 48000) it will
> sound like a metronome!
> If i'll set it as it should be: Decimation: 4800 (=1000) and
> Interpolation: 48 (48 * 1000 = 48 KHz)
> It will throw RuntimeError: audio_alsa_sink.
> 
> I've tried many different settings Rationel Resampler and if
> Interpolation is not set to 48000, it will create and RuntimeError.
> 
> If i do the test on windows with:
> Source: sample rate: 48k -> Rationel Resampler: Interpolation: 1,
> Decimation: 1 -> Audio Sink
> It will work and procuce 1KHz tone.
> 
> Doing the same on RPi 3:
> And it throws a RuntimeError.
> If I then change Rationel Resampler: Interpolation 48000
> It will run without RuntimeError and with no sound!
> 
> So i'll think this is not about a copy / paste error.
> All block used in these test, are with the same Types float 32.
> 
> So i'm quit sure that is something wrong with the Rationel Resampler
> block i RPi - Jessie version.
> 
> Best regards
> Robin.
> 
> Den 19-02-2017 kl. 20:39 skrev Marcus Müller:
>> *high five*, got it to work!
>>
>> So, why the rational resampler?! makes no sense, especially since both
>> interpolation and decimation need to be integers; since it doesn't make
>> sense mathematical, is it possible you did something slightly different
>> on Windows?
>>
>> Resamplers are *only* necessary to convert a signal from one sampling
>> rate to another mathematically, without changing the signal's content.
>> The rate change is interpolation/decimation. If your original signal is
>> already at the right sampling rate, adding a resampler in between will
>> only *break* things.
>>
>> The RuntimeError has something to do with how you configure the audio
>> sink. so, you need to use exactly the same config, ie. 2 inputs, hw:0,
>> sampling rate 48000. It doesn't come from having the wrong kind of
>> resampling before that. GNU Radio blocks really don't care at all about
>> what happens upstream. They get a series of numbers they process.
>>
>> There's no reason for multiple resamplers. Please take this as a
>> constructive criticism: You must stop using a copy and paste approach,
>> and go for an understanding-based approach.
>>
>> So let's work from the ends: We know we have an audio sink that we need
>> to run at 48000 as sampling rate, and in the end, we'll need to connect
>> that to a RTL source that gives us 2 MS/s. So in total, from source to
>> sink, we need a resampling ratio of 2e6/48e3. I'll do it the boring way
>> here, by using a prime factorization of both, to figure out how we can
>> group these:
>>
>> 2e6 = 2 · 10⁶ = 2 · (2·5)⁶
>> = 5⁶ · 2⁶
>>
>> 48e3 = 48 · 10³ = 3 · 16 · (2·5)³ = 3 · 2⁴ · 2³ · 5³
>> = 5³ · 3 · 2⁷
>>
>> Let's divide these two numbers so that we know what our overall
>> resampling ratio is:
>>
>> 2e6/48e3 = (5⁶ · 2⁶)/(5³ · 3 · 2⁷) and cancelling out everything that's
>> possible to cancel
>> 5³ / (3 · 2)
>>
>> So what we need is a decimation of 5³ = 125 and an interpolation of 6.
>> Awesome! Let's make that happen.
>>
>> We know that we have at least one block that we need to use between RTL
>> source and Audio sink: the WBFM receive. Let's plug that directly into
>> the Audio Sink. That means we know its output rate, because it *must* be
>> the 48k that said audio sink consumes. Ok, let's see, we need to
>> decimate by 5³ in total, so let's put the "Audio Decimation" to 5 here.
>> That leaves us with still 5² to decimate, and 6 to interpolate. (we also
>> can directly calculate that the

Re: [Discuss-gnuradio] OOT module with a vector input/output gives an assertion failure

2017-02-19 Thread Marcus Müller

1. Make sure you're not mixing up vectors and individual elements. You must 
return the number of vectors you've produced, not the number of gr_complexes 
these contain.
2. Separately calling consume_each and returning the same value looks like you 
should have used a sync block (with a work function) instead of a general block 
(with a general_work function). If you're already actually using a work/sync 
block, then returning a number implicitly consumes! In that case, you're 
consuming twice the amount of items you should.

Best regards,
Marcus

Am 19. Februar 2017 21:34:00 MEZ schrieb Damindra Bandara 
:
>Hi,
>
>I am trying to create an OOT module with a vector input. I haven't
>implemented the signal processing yet. This is how my code looks like.
>
>
>*I/O signature*
>
>gr::io_signature::make(1, 1, sizeof(gr_complex)*fft_len),
>  gr::io_signature::make(1, 1, sizeof(gr_complex)*fft_len))
>
>*In the work function,*
>
>const gr_complex *in = (const gr_complex *) input_items[0];
>gr_complex *out = (gr_complex *) output_items[0];
>
> consume_each (noutput_items);
> return noutput_items;
>
>When the fft_len is set to 1, the block runs without any errors.
>However,
>when I set the fft_len to some value greater than 1, it fails with the
>following error.
>
>python2:
>/usr/local/src/gnuradio/gnuradio-runtime/include/gnuradio/buffer.h:179:
>unsigned int gr::buffer::index_add(unsigned int, unsigned int):
>Assertion
>`s < d_bufsize' failed.
>
>I appreciate if you could give me some guidance to get this fixed.
>
>Thanks,
>Damindra
>
>-- 
>Damindra Savithri Bandara,
>Ph.D. in Information Technology (Candidate)
>George Mason University,
>Fairfax,
>Virginia

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU radio resources for emitters identification, wireless PHY identification

2017-02-19 Thread Vincentzio Roman

Hello,


Anybody knows of GNU radio resources or products for emitters
identification, and/or wireless PHY identification? I saw a few spectrum
sensing sample programs, but I need something in the idea of identification
using radiometry, signal features or cyclostationary analysis.


Cheers,
Vincent
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT module with a vector input/output gives an assertion failure

2017-02-19 Thread Damindra Bandara

Hi,

I am trying to create an OOT module with a vector input. I haven't
implemented the signal processing yet. This is how my code looks like.


*I/O signature*

gr::io_signature::make(1, 1, sizeof(gr_complex)*fft_len),
  gr::io_signature::make(1, 1, sizeof(gr_complex)*fft_len))

*In the work function,*

const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];

 consume_each (noutput_items);
 return noutput_items;

When the fft_len is set to 1, the block runs without any errors. However,
when I set the fft_len to some value greater than 1, it fails with the
following error.

python2: /usr/local/src/gnuradio/gnuradio-runtime/include/gnuradio/buffer.h:179:
unsigned int gr::buffer::index_add(unsigned int, unsigned int): Assertion
`s < d_bufsize' failed.

I appreciate if you could give me some guidance to get this fixed.

Thanks,
Damindra

-- 
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Robin A. Jensen


Hello Marcus.

I've haven't copy  pasted!
I made it from a tutorial and it will work on Window 10 machine. :-)

Now i have tried your suggestion and the RuntimeError is till persist.
But you lost min the part, about moving the resampler in front of WBFM.
I did it and the Runtime error is still presentet.

But i'm sure that there is a bug in the debian versin of GNU Radio 
Companion 3.7.5 when using Rationel Resampler.
It's making no sense. I have understood the concept of Decimating and 
Interpolation.
I now have done some test with exactly the same simple setup on Windows 
10 and RPi 3 Jessie.

On Windows:
Souce: resample 480 k Waveform: Cosine, Freq: 1k->
Rationel Resampler: Decimation 480 (= 1000), Interpolation 48 (=48.000) ->
Audio Sink: Sample Rate: 48k

It will produce a tone of 1 KHz.

Doing precise the same on RPi 3:
RuntimeError: audio_alsa_sink
Only when Rationel Resampler is set to: Interpolation 48000,
It will run, but if Decimation is 480 (= 1000 -> 1000 * 48000) it will 
sound like a metronome!
If i'll set it as it should be: Decimation: 4800 (=1000) and 
Interpolation: 48 (48 * 1000 = 48 KHz)

It will throw RuntimeError: audio_alsa_sink.

I've tried many different settings Rationel Resampler and if 
Interpolation is not set to 48000, it will create and RuntimeError.


If i do the test on windows with:
Source: sample rate: 48k -> Rationel Resampler: Interpolation: 1, 
Decimation: 1 -> Audio Sink

It will work and procuce 1KHz tone.

Doing the same on RPi 3:
And it throws a RuntimeError.
If I then change Rationel Resampler: Interpolation 48000
It will run without RuntimeError and with no sound!

So i'll think this is not about a copy / paste error.
All block used in these test, are with the same Types float 32.

So i'm quit sure that is something wrong with the Rationel Resampler 
block i RPi - Jessie version.


Best regards
Robin.

Den 19-02-2017 kl. 20:39 skrev Marcus Müller:

*high five*, got it to work!

So, why the rational resampler?! makes no sense, especially since both
interpolation and decimation need to be integers; since it doesn't make
sense mathematical, is it possible you did something slightly different
on Windows?

Resamplers are *only* necessary to convert a signal from one sampling
rate to another mathematically, without changing the signal's content.
The rate change is interpolation/decimation. If your original signal is
already at the right sampling rate, adding a resampler in between will
only *break* things.

The RuntimeError has something to do with how you configure the audio
sink. so, you need to use exactly the same config, ie. 2 inputs, hw:0,
sampling rate 48000. It doesn't come from having the wrong kind of
resampling before that. GNU Radio blocks really don't care at all about
what happens upstream. They get a series of numbers they process.

There's no reason for multiple resamplers. Please take this as a
constructive criticism: You must stop using a copy and paste approach,
and go for an understanding-based approach.

So let's work from the ends: We know we have an audio sink that we need
to run at 48000 as sampling rate, and in the end, we'll need to connect
that to a RTL source that gives us 2 MS/s. So in total, from source to
sink, we need a resampling ratio of 2e6/48e3. I'll do it the boring way
here, by using a prime factorization of both, to figure out how we can
group these:

2e6 = 2 · 10⁶ = 2 · (2·5)⁶
= 5⁶ · 2⁶

48e3 = 48 · 10³ = 3 · 16 · (2·5)³ = 3 · 2⁴ · 2³ · 5³
= 5³ · 3 · 2⁷

Let's divide these two numbers so that we know what our overall
resampling ratio is:

2e6/48e3 = (5⁶ · 2⁶)/(5³ · 3 · 2⁷) and cancelling out everything that's
possible to cancel
5³ / (3 · 2)

So what we need is a decimation of 5³ = 125 and an interpolation of 6.
Awesome! Let's make that happen.

We know that we have at least one block that we need to use between RTL
source and Audio sink: the WBFM receive. Let's plug that directly into
the Audio Sink. That means we know its output rate, because it *must* be
the 48k that said audio sink consumes. Ok, let's see, we need to
decimate by 5³ in total, so let's put the "Audio Decimation" to 5 here.
That leaves us with still 5² to decimate, and 6 to interpolate. (we also
can directly calculate that the *input* of the WBFM receive must be 5 ·
48kS/s = 240 kS/s). And since we have two channels on our audio sink,
connect the both Audio sink inputs to the one autput of WBFM receive.

Well, then, let's do that: add a rational resampler that has decimation
= 25 and interpolation = 6. Connect its output directly to WBFM receive,
and its input to the RTL source. Done!


Best regards,

Marcus


On 19.02.2017 19:42, Robin A. Jensen wrote:

Hello again.

Now i've a little test.
Signal Source: sample rate: 48k, Waveform: Cosine, freq: 1k amplitude:
1 ->

Audio Sink: Samp_rate: 48 k, Devicename: hw:0 (with 2 inputs)

And that is a succes! There a sound.
It will only run with 48k as sample rate.
So now we know there are an output for real. :-)

But

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Marcus Müller

*high five*, got it to work!

So, why the rational resampler?! makes no sense, especially since both
interpolation and decimation need to be integers; since it doesn't make
sense mathematical, is it possible you did something slightly different
on Windows?

Resamplers are *only* necessary to convert a signal from one sampling
rate to another mathematically, without changing the signal's content.
The rate change is interpolation/decimation. If your original signal is
already at the right sampling rate, adding a resampler in between will
only *break* things.

The RuntimeError has something to do with how you configure the audio
sink. so, you need to use exactly the same config, ie. 2 inputs, hw:0,
sampling rate 48000. It doesn't come from having the wrong kind of
resampling before that. GNU Radio blocks really don't care at all about
what happens upstream. They get a series of numbers they process.

There's no reason for multiple resamplers. Please take this as a
constructive criticism: You must stop using a copy and paste approach,
and go for an understanding-based approach.

So let's work from the ends: We know we have an audio sink that we need
to run at 48000 as sampling rate, and in the end, we'll need to connect
that to a RTL source that gives us 2 MS/s. So in total, from source to
sink, we need a resampling ratio of 2e6/48e3. I'll do it the boring way
here, by using a prime factorization of both, to figure out how we can
group these:

2e6 = 2 · 10⁶ = 2 · (2·5)⁶
= 5⁶ · 2⁶

48e3 = 48 · 10³ = 3 · 16 · (2·5)³ = 3 · 2⁴ · 2³ · 5³
= 5³ · 3 · 2⁷

Let's divide these two numbers so that we know what our overall
resampling ratio is:

2e6/48e3 = (5⁶ · 2⁶)/(5³ · 3 · 2⁷) and cancelling out everything that's
possible to cancel
5³ / (3 · 2)

So what we need is a decimation of 5³ = 125 and an interpolation of 6.
Awesome! Let's make that happen.

We know that we have at least one block that we need to use between RTL
source and Audio sink: the WBFM receive. Let's plug that directly into
the Audio Sink. That means we know its output rate, because it *must* be
the 48k that said audio sink consumes. Ok, let's see, we need to
decimate by 5³ in total, so let's put the "Audio Decimation" to 5 here.
That leaves us with still 5² to decimate, and 6 to interpolate. (we also
can directly calculate that the *input* of the WBFM receive must be 5 ·
48kS/s = 240 kS/s). And since we have two channels on our audio sink,
connect the both Audio sink inputs to the one autput of WBFM receive.

Well, then, let's do that: add a rational resampler that has decimation
= 25 and interpolation = 6. Connect its output directly to WBFM receive,
and its input to the RTL source. Done!

Best regards,

Marcus

On 19.02.2017 19:42, Robin A. Jensen wrote:
> Hello again.
>
> Now i've a little test.
> Signal Source: sample rate: 48k, Waveform: Cosine, freq: 1k amplitude:
> 1 ->
>
> Audio Sink: Samp_rate: 48 k, Devicename: hw:0 (with 2 inputs)
>
> And that is a succes! There a sound.
> It will only run with 48k as sample rate.
> So now we know there are an output for real. :-)
>
> But if i put in Rationel Resampler: Interpolation: 1 / 48k,
> Decimation: 1 and Source is 48k.
> There is no sound..??
> No mather how i fidle around with the values.
> I've tried with different settings for the Sampler and also Rationel
> Resampler Base, with no change regard to the output.
> I find it really strange as the Rationel Resampler is working on a
> Windows 10.
>
> I then whent back to my WBFM setup and remove the resampler and run it
> direcly from WBFM to Auduo Sink,
> and then the RuntimeError came back :-(
>
> Best regard
> Robin.
>
>
> Den 19-02-2017 kl. 18:06 skrev Marcus Müller:
>> Hi Robin,
>>
>> Progress! (and you really don't have to try anything in lower- AND
>> uppercase. the names are simply case-sensitive, so use them **exactly**
>> like aplay -L lists them. Everything else can't work. There's really no
>> magic involved here! Stop googling stuff that you copy and paste. You've
>> got a discrete problem on *your* machine, and you can solve it, so copy
>> and pasting device strings that work on other people's computer's is
>> really not that helpful.)
>>
>>> It returns: check topology failed on on audio_alsa_sink(8) using
>>> ninputs=1, noutputs=0
>> Now that means you're using a device it can find. so: yeah, we're doing
>> something right. I'd really recommend you stick with "pulse", as that
>> will make sure of mixing all the audio streams other programs produce
>> together with yours and you'll not compete for exclusive access to the
>> audio device. It *should* give you at least the same check_topology
>> error. Can you please confirm that?
>>
>> Best regards,
>>
>> Marcus
>>
>>
>>
>> On 19.02.2017 16:42, Robin A. Jensen wrote:
>>> Hey Marcus.
>>>
>>> Have tried that.
>>> In documentation for the block:
>>> pulse , hw:0,0 , plughw:0,0 , surround51 , /dev/dsp
>>>
>>> I've tried every single one of them with lowercase and upper case.
>>>
>>> If i use:

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Robin A. Jensen


Hello again.

Now i've a little test.
Signal Source: sample rate: 48k, Waveform: Cosine, freq: 1k amplitude: 1 ->

Audio Sink: Samp_rate: 48 k, Devicename: hw:0 (with 2 inputs)

And that is a succes! There a sound.
It will only run with 48k as sample rate.
So now we know there are an output for real. :-)

But if i put in Rationel Resampler: Interpolation: 1 / 48k, Decimation: 
1 and Source is 48k.

There is no sound..??
No mather how i fidle around with the values.
I've tried with different settings for the Sampler and also Rationel 
Resampler Base, with no change regard to the output.
I find it really strange as the Rationel Resampler is working on a 
Windows 10.


I then whent back to my WBFM setup and remove the resampler and run it 
direcly from WBFM to Auduo Sink,

and then the RuntimeError came back :-(

Best regard
Robin.


Den 19-02-2017 kl. 18:06 skrev Marcus Müller:

Hi Robin,

Progress! (and you really don't have to try anything in lower- AND
uppercase. the names are simply case-sensitive, so use them **exactly**
like aplay -L lists them. Everything else can't work. There's really no
magic involved here! Stop googling stuff that you copy and paste. You've
got a discrete problem on *your* machine, and you can solve it, so copy
and pasting device strings that work on other people's computer's is
really not that helpful.)


It returns: check topology failed on on audio_alsa_sink(8) using
ninputs=1, noutputs=0

Now that means you're using a device it can find. so: yeah, we're doing
something right. I'd really recommend you stick with "pulse", as that
will make sure of mixing all the audio streams other programs produce
together with yours and you'll not compete for exclusive access to the
audio device. It *should* give you at least the same check_topology
error. Can you please confirm that?

Best regards,

Marcus



On 19.02.2017 16:42, Robin A. Jensen wrote:

Hey Marcus.

Have tried that.
In documentation for the block:
pulse , hw:0,0 , plughw:0,0 , surround51 , /dev/dsp

I've tried every single one of them with lowercase and upper case.

If i use: hw:0,0
It returns: check topology failed on on audio_alsa_sink(8) using
ninputs=1, noutputs=0
If I use: HW:0,0
It returns: RuntimeError: audio_alsa_sink.

I've also tried with: HW:0,1 , HW:1,0 , HW:0.1 , HW:1.0 also in lower
case.
I've been tried to google with different search terms with no luck.
That's why I ended up on this mailing list.

GNU Radio is downloaded from rpi Jessie repository with apt-get
install gnuradio.

Best regards
Robin.

Den 19-02-2017 kl. 16:25 skrev Marcus Müller:

Hm, that looks like there's no HW in the list, so that would be an
initial debugging success!

So, the easiest is probably if you just use "pulse" in the Device Name
field.

Best regards,

Marcus


On 19.02.2017 16:15, Robin A. Jensen wrote:

Yes of course.
Here we go:

aplay -L

null
  Discard all samples (playback) or generate zero samples (capture)

pulse
  PulseAudio Sound Server
sysdefault:CARD=ALSA
  bcm2835 ALSA, bcm2835 ALSA
  Default Audio Device

dmix:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Direct sample mixing device

dmix:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Direct sample mixing device

dsnoop:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Direct sample snooping device

dsnoop:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Direct sample snooping device

hw:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Direct hardware device without any conversions

hw:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Direct hardware device without any conversions

plughw:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Hardware device with all software conversions

plughw:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Hardware device with all software conversions

If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
I'll get a fine sinus tone.
So there are sound through the system.

Best regards
Robin.


Den 19-02-2017 kl. 15:48 skrev Marcus Müller:

You're right, we should tackle this more systematically.

My problem is that I don't have a RPi3 to play around with at hand,
so I
have to trust you on the "HW:0,0"; it's not a very typical string,
through, as most alsa device names are lowercase. Could you share the
output of "aplay -L" with us?

Best regards,
Marcus

On 19.02.2017 15:16, Robin A. Jensen wrote:

Hello Marcus.

Thanks for your reply and your welcomming to the community.

I've made the changes as suggested.
Also i've made a setup on a Windows 10 machine, to ensure the script
runs.
With the changes the sound is much better! :-)

But when i run the same setup on RPi 3 / Jessie-distro i've end up
with the same result, no matter what I do with the Audio sink.
I'm using Gnu Radio Companion 3.7.5
The error code is still:

ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10
times this line
gr::log :ERROR: audio_alsa_sink0 -

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Marcus Müller

Hm, 'kay, didn't expect that. Anyway, can you try the **verbatim** other
device names from aplay -L? I'd start with "dmix:CARD=ALSA,DEV=0"; and
go for these starting with plughw after. It's pretty likely that the
"hw:…" interfaces are a little touchy when it comes to supported audio
rates and formats, see their description in aplay -L.

Point is that we're guessworking our way forward through your Audio
system. I'm not saying it's impossible there's a bug in gr-audio, and
Fons' work on the JACK interfaces certainly highlighted that audio
subsystem problems can go unnoticed if usage of that interface uncommon,
but as practically everyone starts with a flow graph similar to yours...
the alsa_sink is rather well-covered by wide usage. A quick google on
the topic revealed that the Pi3 seems to be a bit tricky to bring to
work with respect to ALSA, so please feel assured that we all can
appreciate your patience with ALSA on specific devices. Many of us have
torn their hair at problems involving getting stuff to put out sound,
not only with GNU Radio.

You said you got rtl_fm and aplay to generate sound: Maybe that's the
next thing to investigate. How **exactly** did you call them. Probably a
good idea is to add the -v option to a working aplay call – that way, it
will show something like

ALSA <-> PulseAudio PCM I/O Plugin

in the second or third line of output, and together with aplay -L this
might be sufficient to work out what we should use.

Best regards,

Marcus

On 19.02.2017 18:18, Robin A. Jensen wrote:
> Hello Marcus
>
> If I use: pulse
> it returns: RuntimeError: audio_alsa_sink
>
> Best regards
> Robin.
>
>
> Den 19-02-2017 kl. 18:06 skrev Marcus Müller:
>> Hi Robin,
>>
>> Progress! (and you really don't have to try anything in lower- AND
>> uppercase. the names are simply case-sensitive, so use them **exactly**
>> like aplay -L lists them. Everything else can't work. There's really no
>> magic involved here! Stop googling stuff that you copy and paste. You've
>> got a discrete problem on *your* machine, and you can solve it, so copy
>> and pasting device strings that work on other people's computer's is
>> really not that helpful.)
>>
>>> It returns: check topology failed on on audio_alsa_sink(8) using
>>> ninputs=1, noutputs=0
>> Now that means you're using a device it can find. so: yeah, we're doing
>> something right. I'd really recommend you stick with "pulse", as that
>> will make sure of mixing all the audio streams other programs produce
>> together with yours and you'll not compete for exclusive access to the
>> audio device. It *should* give you at least the same check_topology
>> error. Can you please confirm that?
>>
>> Best regards,
>>
>> Marcus
>>
>>
>>
>> On 19.02.2017 16:42, Robin A. Jensen wrote:
>>> Hey Marcus.
>>>
>>> Have tried that.
>>> In documentation for the block:
>>> pulse , hw:0,0 , plughw:0,0 , surround51 , /dev/dsp
>>>
>>> I've tried every single one of them with lowercase and upper case.
>>>
>>> If i use: hw:0,0
>>> It returns: check topology failed on on audio_alsa_sink(8) using
>>> ninputs=1, noutputs=0
>>> If I use: HW:0,0
>>> It returns: RuntimeError: audio_alsa_sink.
>>>
>>> I've also tried with: HW:0,1 , HW:1,0 , HW:0.1 , HW:1.0 also in lower
>>> case.
>>> I've been tried to google with different search terms with no luck.
>>> That's why I ended up on this mailing list.
>>>
>>> GNU Radio is downloaded from rpi Jessie repository with apt-get
>>> install gnuradio.
>>>
>>> Best regards
>>> Robin.
>>>
>>> Den 19-02-2017 kl. 16:25 skrev Marcus Müller:
 Hm, that looks like there's no HW in the list, so that would be an
 initial debugging success!

 So, the easiest is probably if you just use "pulse" in the Device Name
 field.

 Best regards,

 Marcus

 On 19.02.2017 16:15, Robin A. Jensen wrote:
> Yes of course.
> Here we go:
>
> aplay -L
>
> null
>   Discard all samples (playback) or generate zero samples
> (capture)
>
> pulse
>   PulseAudio Sound Server
> sysdefault:CARD=ALSA
>   bcm2835 ALSA, bcm2835 ALSA
>   Default Audio Device
>
> dmix:CARD=ALSA,DEV=0
>   bcm2835 ALSA, bcm2835 ALSA
>   Direct sample mixing device
>
> dmix:CARD=ALSA,DEV=1
>   bcm2835 ALSA, bcm2835 IEC958/HDMI
>   Direct sample mixing device
>
> dsnoop:CARD=ALSA,DEV=0
>   bcm2835 ALSA, bcm2835 ALSA
>   Direct sample snooping device
>
> dsnoop:CARD=ALSA,DEV=1
>   bcm2835 ALSA, bcm2835 IEC958/HDMI
>   Direct sample snooping device
>
> hw:CARD=ALSA,DEV=0
>   bcm2835 ALSA, bcm2835 ALSA
>   Direct hardware device without any conversions
>
> hw:CARD=ALSA,DEV=1
>   bcm2835 ALSA, bcm2835 IEC958/HDMI
>   Direct hardware device without any conversions
>
> plughw:CARD=ALSA,DEV=0
>   bcm2835 ALSA, bcm2835 ALSA
>   Hardware

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Robin A. Jensen


Hello Marcus

If I use: pulse
it returns: RuntimeError: audio_alsa_sink

Best regards
Robin.


Den 19-02-2017 kl. 18:06 skrev Marcus Müller:

Hi Robin,

Progress! (and you really don't have to try anything in lower- AND
uppercase. the names are simply case-sensitive, so use them **exactly**
like aplay -L lists them. Everything else can't work. There's really no
magic involved here! Stop googling stuff that you copy and paste. You've
got a discrete problem on *your* machine, and you can solve it, so copy
and pasting device strings that work on other people's computer's is
really not that helpful.)


It returns: check topology failed on on audio_alsa_sink(8) using
ninputs=1, noutputs=0

Now that means you're using a device it can find. so: yeah, we're doing
something right. I'd really recommend you stick with "pulse", as that
will make sure of mixing all the audio streams other programs produce
together with yours and you'll not compete for exclusive access to the
audio device. It *should* give you at least the same check_topology
error. Can you please confirm that?

Best regards,

Marcus



On 19.02.2017 16:42, Robin A. Jensen wrote:

Hey Marcus.

Have tried that.
In documentation for the block:
pulse , hw:0,0 , plughw:0,0 , surround51 , /dev/dsp

I've tried every single one of them with lowercase and upper case.

If i use: hw:0,0
It returns: check topology failed on on audio_alsa_sink(8) using
ninputs=1, noutputs=0
If I use: HW:0,0
It returns: RuntimeError: audio_alsa_sink.

I've also tried with: HW:0,1 , HW:1,0 , HW:0.1 , HW:1.0 also in lower
case.
I've been tried to google with different search terms with no luck.
That's why I ended up on this mailing list.

GNU Radio is downloaded from rpi Jessie repository with apt-get
install gnuradio.

Best regards
Robin.

Den 19-02-2017 kl. 16:25 skrev Marcus Müller:

Hm, that looks like there's no HW in the list, so that would be an
initial debugging success!

So, the easiest is probably if you just use "pulse" in the Device Name
field.

Best regards,

Marcus


On 19.02.2017 16:15, Robin A. Jensen wrote:

Yes of course.
Here we go:

aplay -L

null
  Discard all samples (playback) or generate zero samples (capture)

pulse
  PulseAudio Sound Server
sysdefault:CARD=ALSA
  bcm2835 ALSA, bcm2835 ALSA
  Default Audio Device

dmix:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Direct sample mixing device

dmix:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Direct sample mixing device

dsnoop:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Direct sample snooping device

dsnoop:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Direct sample snooping device

hw:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Direct hardware device without any conversions

hw:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Direct hardware device without any conversions

plughw:CARD=ALSA,DEV=0
  bcm2835 ALSA, bcm2835 ALSA
  Hardware device with all software conversions

plughw:CARD=ALSA,DEV=1
  bcm2835 ALSA, bcm2835 IEC958/HDMI
  Hardware device with all software conversions

If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
I'll get a fine sinus tone.
So there are sound through the system.

Best regards
Robin.


Den 19-02-2017 kl. 15:48 skrev Marcus Müller:

You're right, we should tackle this more systematically.

My problem is that I don't have a RPi3 to play around with at hand,
so I
have to trust you on the "HW:0,0"; it's not a very typical string,
through, as most alsa device names are lowercase. Could you share the
output of "aplay -L" with us?

Best regards,
Marcus

On 19.02.2017 15:16, Robin A. Jensen wrote:

Hello Marcus.

Thanks for your reply and your welcomming to the community.

I've made the changes as suggested.
Also i've made a setup on a Windows 10 machine, to ensure the script
runs.
With the changes the sound is much better! :-)

But when i run the same setup on RPi 3 / Jessie-distro i've end up
with the same result, no matter what I do with the Audio sink.
I'm using Gnu Radio Companion 3.7.5
The error code is still:

ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10
times this line
gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or
directory.
File "/home/pi/radio/top_block.py", line133, in 
tb= top_block()
File "/home/pi/radio/top_block.py", line82, in __init__
self.audio_sink_0 = audio.sink(48000, "HW:0,0", True)
File "/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py",
line 195, in make
return _ausio_swig.sink_make(*args, **kwargs)
RuntimeError: audio_alsa_sink

I know is alwayes is eassy to blame the software, but could it be a
bug?
As i said. i've tried with all the suggested lines from documentation
of the block.

Best regards
Robin.

Den 18-02-2017 kl. 18:17 skrev Marcus Müller:

Hi Robin,

first of all: Welcome to the GNU Radio community!


On 02/18/2017 05:29 PM, Robin A. Jensen wrote:

Hello all of you.

I've just

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Marcus Müller

Hi Robin,

Progress! (and you really don't have to try anything in lower- AND
uppercase. the names are simply case-sensitive, so use them **exactly**
like aplay -L lists them. Everything else can't work. There's really no
magic involved here! Stop googling stuff that you copy and paste. You've
got a discrete problem on *your* machine, and you can solve it, so copy
and pasting device strings that work on other people's computer's is
really not that helpful.)

> It returns: check topology failed on on audio_alsa_sink(8) using
> ninputs=1, noutputs=0 

Now that means you're using a device it can find. so: yeah, we're doing
something right. I'd really recommend you stick with "pulse", as that
will make sure of mixing all the audio streams other programs produce
together with yours and you'll not compete for exclusive access to the
audio device. It *should* give you at least the same check_topology
error. Can you please confirm that?

Best regards,

Marcus



On 19.02.2017 16:42, Robin A. Jensen wrote:
> Hey Marcus.
>
> Have tried that.
> In documentation for the block:
> pulse , hw:0,0 , plughw:0,0 , surround51 , /dev/dsp
>
> I've tried every single one of them with lowercase and upper case.
>
> If i use: hw:0,0
> It returns: check topology failed on on audio_alsa_sink(8) using
> ninputs=1, noutputs=0
> If I use: HW:0,0
> It returns: RuntimeError: audio_alsa_sink.
>
> I've also tried with: HW:0,1 , HW:1,0 , HW:0.1 , HW:1.0 also in lower
> case.
> I've been tried to google with different search terms with no luck.
> That's why I ended up on this mailing list.
>
> GNU Radio is downloaded from rpi Jessie repository with apt-get
> install gnuradio.
>
> Best regards
> Robin.
>
> Den 19-02-2017 kl. 16:25 skrev Marcus Müller:
>> Hm, that looks like there's no HW in the list, so that would be an
>> initial debugging success!
>>
>> So, the easiest is probably if you just use "pulse" in the Device Name
>> field.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 19.02.2017 16:15, Robin A. Jensen wrote:
>>> Yes of course.
>>> Here we go:
>>>
>>> aplay -L
>>>
>>> null
>>>  Discard all samples (playback) or generate zero samples (capture)
>>>
>>> pulse
>>>  PulseAudio Sound Server
>>> sysdefault:CARD=ALSA
>>>  bcm2835 ALSA, bcm2835 ALSA
>>>  Default Audio Device
>>>
>>> dmix:CARD=ALSA,DEV=0
>>>  bcm2835 ALSA, bcm2835 ALSA
>>>  Direct sample mixing device
>>>
>>> dmix:CARD=ALSA,DEV=1
>>>  bcm2835 ALSA, bcm2835 IEC958/HDMI
>>>  Direct sample mixing device
>>>
>>> dsnoop:CARD=ALSA,DEV=0
>>>  bcm2835 ALSA, bcm2835 ALSA
>>>  Direct sample snooping device
>>>
>>> dsnoop:CARD=ALSA,DEV=1
>>>  bcm2835 ALSA, bcm2835 IEC958/HDMI
>>>  Direct sample snooping device
>>>
>>> hw:CARD=ALSA,DEV=0
>>>  bcm2835 ALSA, bcm2835 ALSA
>>>  Direct hardware device without any conversions
>>>
>>> hw:CARD=ALSA,DEV=1
>>>  bcm2835 ALSA, bcm2835 IEC958/HDMI
>>>  Direct hardware device without any conversions
>>>
>>> plughw:CARD=ALSA,DEV=0
>>>  bcm2835 ALSA, bcm2835 ALSA
>>>  Hardware device with all software conversions
>>>
>>> plughw:CARD=ALSA,DEV=1
>>>  bcm2835 ALSA, bcm2835 IEC958/HDMI
>>>  Hardware device with all software conversions
>>>
>>> If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
>>> I'll get a fine sinus tone.
>>> So there are sound through the system.
>>>
>>> Best regards
>>> Robin.
>>>
>>>
>>> Den 19-02-2017 kl. 15:48 skrev Marcus Müller:
 You're right, we should tackle this more systematically.

 My problem is that I don't have a RPi3 to play around with at hand,
 so I
 have to trust you on the "HW:0,0"; it's not a very typical string,
 through, as most alsa device names are lowercase. Could you share the
 output of "aplay -L" with us?

 Best regards,
 Marcus

 On 19.02.2017 15:16, Robin A. Jensen wrote:
> Hello Marcus.
>
> Thanks for your reply and your welcomming to the community.
>
> I've made the changes as suggested.
> Also i've made a setup on a Windows 10 machine, to ensure the script
> runs.
> With the changes the sound is much better! :-)
>
> But when i run the same setup on RPi 3 / Jessie-distro i've end up
> with the same result, no matter what I do with the Audio sink.
> I'm using Gnu Radio Companion 3.7.5
> The error code is still:
>
> ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10
> times this line
> gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or
> directory.
> File "/home/pi/radio/top_block.py", line133, in 
>tb= top_block()
> File "/home/pi/radio/top_block.py", line82, in __init__
> self.audio_sink_0 = audio.sink(48000, "HW:0,0", True)
> File "/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py",
> line 195, in make
> return _ausio_swig.sink_make(*args, **kwargs)
> RuntimeError: audio_alsa_sink
>
> I know is alwayes is eassy to

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Fons Adriaensen

On Sun, Feb 19, 2017 at 04:25:10PM +0100, Marcus Müller wrote:

> Hm, that looks like there's no HW in the list, so that would be an
> initial debugging success!
> So, the easiest is probably if you just use "pulse" in the Device Name
> field.

It must be lower case: hw:0.0
Also make sure Pulse isn't using the device. Best thing regading
Pulse is to completely remove or disable it. 

This reminds me of the Jack sink/source driver which I fixed
some time ago. It worked OK until a few weeks ago when I did a
git pull and complete rebuild. Since then nothing works.

No matter what I do with PYTHONPATH I get either 

'no module named gnuradio'

or 

'no module name _runtime_swig'

My default python is (and has to be) python3.6, but I have
python2.7 and the first line of my test programs is

#!/usr/bin/env python2

Things used to work that way.

Python2.7 is in /usr/* while gnuradio's stuff (including the
python parts) is in /usr/local/*. Can this be a problem ?
If yes how do I convince cmake to install in /usr/* ?

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Robin A. Jensen

Hello Volker

If i change Audio Sink to 2 channels and split signal from Rationel
Resampler, i'll get error:

RuntimeError: audio_alsa_sink
:-(

Best regards
Robin.

Den 19-02-2017 kl. 17:27 skrev Volker Schroer:

Hi Robin,
I think that the PI audio hardware is stereo.
So set in your audio sink the number of inputs to to and than connect
the second input channel to the same port of the preceding port the
first channel is connected to.

-- Volker

Am 19.02.2017 um 17:17 schrieb Robin A. Jensen:

Hello Volker

My audiosink is in mono. 1 input.
If I put in a 2. Rationel Sampler and gonnect it's input to WBFM Revicer
and then put Rat. Samp. 2 to a second input on audio sink, i'll get:
RuntimeError: audio_alsa_sink
don't know another way to make WBFM into 2 channel?

Best regards
Robin.

Den 19-02-2017 kl. 17:05 skrev Volker Schroer:

Hi Robin,
that means , you got the correct device name, but your selected
topology is wrong. That happens for example if you provide one input
to a stereo device.

-- Volker

Am 19.02.2017 um 16:52 schrieb Robin A. Jensen:

Hello Volker

It will still create error:
RuntimeError: check topology failed on audio_alsasink(8) using
ninputs=1, noutputs=0

Best regards
Robin.

Den 19-02-2017 kl. 16:44 skrev Volker Schroer:

Robin,
try to use hw:0 or plughw:0 as device string.

The hardware device must be written in lowercase.

If I user uppercase I get the same error as you reported.

ALSA lib
/var/tmp/portage/media-libs/alsa-lib-1.1.2/work/alsa-lib-1.1.2/src/pcm/pcm.c:2450:(snd_pcm_open_noupdate)

Unknown PCM HW:2,0
ERROR: [HW:2,0]: Datei oder Verzeichnis nicht gefunden

If in lowercase:

audio_alsa_sink[hw:2,0]: using S32_LE

-- Volker

Am 19.02.2017 um 16:15 schrieb Robin A. Jensen:

Yes of course.
Here we go:

aplay -L

null
Discard all samples (playback) or generate zero samples
(capture)

pulse
PulseAudio Sound Server
sysdefault:CARD=ALSA
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device

dmix:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device

dmix:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device

dsnoop:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device

dsnoop:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device

hw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions

hw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions

plughw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions

plughw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions

If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
I'll get a fine sinus tone.
So there are sound through the system.

Best regards
Robin.

Den 19-02-2017 kl. 15:48 skrev Marcus Müller:

You're right, we should tackle this more systematically.

My problem is that I don't have a RPi3 to play around with at hand,
so I
have to trust you on the "HW:0,0"; it's not a very typical string,
through, as most alsa device names are lowercase. Could you
share the

output of "aplay -L" with us?

Best regards,
Marcus

On 19.02.2017 15:16, Robin A. Jensen wrote:

Hello Marcus.

Thanks for your reply and your welcomming to the community.

I've made the changes as suggested.
Also i've made a setup on a Windows 10 machine, to ensure the
script

runs.
With the changes the sound is much better! :-)

But when i run the same setup on RPi 3 / Jessie-distro i've end up
with the same result, no matter what I do with the Audio sink.
I'm using Gnu Radio Companion 3.7.5
The error code is still:

ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0
<-- 10

times this line
gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or
directory.
File "/home/pi/radio/top_block.py", line133, in
tb= top_block()
File "/home/pi/radio/top_block.py", line82, in __init__
self.audio_sink_0 = audio.sink(48000, "HW:0,0", True)
File
"/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py",
line 195, in make
return _ausio_swig.sink_make(*args, **kwargs)
RuntimeError: audio_alsa_sink

I know is alwayes is eassy to blame the software, but could it
be a

bug?
As i said. i've tried with all the suggested lines from
documentation
of the block.

Best regards
Robin.

Den 18-02-2017 kl. 18:17 skrev Marcus Müller:

Hi Robin,

first of all: Welcome to the GNU Radio community!

On 02/18/2017 05:29 PM, Robin A. Jensen wrote:

Hello all of you.

I've just recieved my RTL-SDR dongle and is all new to this
sdr-stuff,
so please bear over with me, if i'm at the wrong place.
I'm using GNU Radio Companion on a RPi 3 and no mather what i'll
do, i
can't get the sound to work.
If a'im using rtl_fm and aplay, i'll get sound but it won't set
on the
radiostation.

aha, so that's good, the sound system as it does work.
You'll

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

2017-02-19 Thread Volker Schroer

-- Volker

Am 19.02.2017 um 17:17 schrieb Robin A. Jensen:

Hello Volker

Best regards
Robin.

Den 19-02-2017 kl. 17:05 skrev Volker Schroer:

Hi Robin,
that means , you got the correct device name, but your selected
topology is wrong. That happens for example if you provide one input
to a stereo device.

-- Volker

Am 19.02.2017 um 16:52 schrieb Robin A. Jensen:

Hello Volker

It will still create error:
RuntimeError: check topology failed on audio_alsasink(8) using
ninputs=1, noutputs=0

Best regards
Robin.

Den 19-02-2017 kl. 16:44 skrev Volker Schroer:

Robin,
try to use hw:0 or plughw:0 as device string.

The hardware device must be written in lowercase.

If I user uppercase I get the same error as you reported.

ALSA lib
/var/tmp/portage/media-libs/alsa-lib-1.1.2/work/alsa-lib-1.1.2/src/pcm/pcm.c:2450:(snd_pcm_open_noupdate)

Unknown PCM HW:2,0
ERROR: [HW:2,0]: Datei oder Verzeichnis nicht gefunden

If in lowercase:

audio_alsa_sink[hw:2,0]: using S32_LE

-- Volker

Am 19.02.2017 um 16:15 schrieb Robin A. Jensen:

Yes of course.
Here we go:

aplay -L

null
Discard all samples (playback) or generate zero samples (capture)