Jackd server running with 16kHz sampling rate

[fotisdr]

Hello,

I've recently purchased a stereo audioinjector sound card for my raspberry pi b 3+. I'm trying at the moment to use real-time audio with a sampling frequency of 16kHz but it doesn't seem to be working, although it's working for higher sampling rates. When I am starting the jackd server with a 16kHz sampling frequency I get the following errors: ALSA: cannot set hardware parameters for capture ALSA: cannot configure capture channel Cannot initialize driver JackServer: :Open failed with -1 Failed to open server

I could successfully start the jackd server with a sampling rate of 16kHz with my cirrus audio card but with this one I can't get it working. Can you help me?

Also, do I need an amplifier in order to use the RCA inputs? Because I tried to connect my headset microphone but no input was produced.

Thank you in advance.

[flatmax]

What command are you using to start jackd ?

Your headset microphone is most likely an electret microphone, for that you will have to connect it to the microphone input - however the original sound card has a microphone in place in the microphone input.

The zero form factor audio injector sound card allows you to wire the electret microphone into the board. You can use a suitable socket and wire the microphone line to the electret input and the headphone lines to the headphone output.

On 29/11/18 12:19 am, fotisdr wrote:

Hello,

I've recently purchased a stereo audioinjector sound card for my raspberry pi b 3+. I'm trying at the moment to use real-time audio with a sampling frequency of 16kHz but it doesn't seem to be working, although it's working for higher sampling rates. When I am starting the jackd server with a 16kHz sampling frequency I get the following errors: ALSA: cannot set hardware parameters for capture ALSA: cannot configure capture channel Cannot initialize driver JackServer: :Open failed with -1 Failed to open server

I could successfully start the jackd server with a sampling rate of 16kHz with my cirrus audio card but with this one I can't get it working. Can you help me?

Also, do I need an amplifier in order to use the RCA inputs? Because I tried to connect my headset microphone but no input was produced.

Thank you in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Audio-Injector/stereo-and-zero/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6BzWJV2aT32ZWUZMTf58c-LMdQkEuks5uzo1fgaJpZM4Y3ler.

[fotisdr]

So, the command I am using to start jackd is: jackd --realtime -d alsa -d hw:audioinjectorpi,0 -p 1024 -r 16000 -n 2 It works for sample rates higher than 16 kHz no matter what the other settings are but for 16 kHz it produces the error I quoted above.

Regarding the input, the stereo audioinjector sound card that I bought has an inbuilt microphone, so I guess it doesn't have a microphone input only RCA, right? (I bought the sound card from your website so I suppose it's the original sound card). However this doesn't matter so much, I can use the inbuilt microphone instead of the headset microphone if it's not possible to connect it. What I need to do now is to run the jackd with 16kHz sampling rate.

[fotisdr]

Any ideas about this? I still can't get my Audio Injector sound card working at a 16 kHz sample rate...

[fotisdr]

http://forum.audioinjector.net/viewtopic.php?f=5&t=5687&p=8466 It's been 4 months now and I'm still struggling to find a solution, please help!

[flatmax]

What happens when you use plughw as the device ?

On 26/3/19 7:45 pm, fotisdr wrote:

http://forum.audioinjector.net/viewtopic.php?f=5&t=5687&p=8466 It's been 4 months now and I'm still struggling to find a solution, please help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-476527413, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B0hg1wYxZpRbYTdIbkkoVj6gnWM9ks5vad42gaJpZM4Y3ler.

[fotisdr]

It works with plughw (it worked before the tweak as well) but the sound quality is terrible.

On Tuesday, March 26, 2019, Matt Flax notifications@github.com wrote:

What happens when you use plughw as the device ?

On 26/3/19 7:45 pm, fotisdr wrote:

http://forum.audioinjector.net/viewtopic.php?f=5&t=5687&p=8466 It's been 4 months now and I'm still struggling to find a solution, please help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-476527413 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAq6B0hg1wYxZpRbYTdIbkkoVj6gnWM9ks5vad42gaJpZM4Y3ler .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.< https://ci6.googleusercontent.com/proxy/RqOoy6Lv-J-lvMHybyKA43fkElROwwqgttSUSHtVArO4VlP8ryZcTeJFczOQ9E_mLo8j40NeWVD-gJfIVFs0at6gwcJu3c7AlFOty0ulHG56QFhGGvy0l79bdR5LNhvLnTIO7tnPggmP-7PBWgd5kpT93w=s0-d-e1-ft#https://github.com/notifications/beacon/AppcV4ykELkIronVpJodVb1bSWkf7y8Uks5vaoihgaJpZM4Y3ler.gif>

[flatmax]

can you share your jackd command with us ?

Also the jackd output once started

Matt

On 27/3/19 5:11 pm, fotisdr wrote:

It works with plughw (it worked before the tweak as well) but the sound quality is terrible.

On Tuesday, March 26, 2019, Matt Flax notifications@github.com wrote:

What happens when you use plughw as the device ?

On 26/3/19 7:45 pm, fotisdr wrote:

http://forum.audioinjector.net/viewtopic.php?f=5&t=5687&p=8466 It's been 4 months now and I'm still struggling to find a solution, please help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-476527413 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAq6B0hg1wYxZpRbYTdIbkkoVj6gnWM9ks5vad42gaJpZM4Y3ler .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.< https://ci6.googleusercontent.com/proxy/RqOoy6Lv-J-lvMHybyKA43fkElROwwqgttSUSHtVArO4VlP8ryZcTeJFczOQ9E_mLo8j40NeWVD-gJfIVFs0at6gwcJu3c7AlFOty0ulHG56QFhGGvy0l79bdR5LNhvLnTIO7tnPggmP-7PBWgd5kpT93w=s0-d-e1-ft#https://github.com/notifications/beacon/AppcV4ykELkIronVpJodVb1bSWkf7y8Uks5vaoihgaJpZM4Y3ler.gif>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-476992907, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B5N0OcbSK50hhMVzYwcLVpSDBFoVks5vawubgaJpZM4Y3ler.

[fotisdr]

can you share your jackd command with us ? Also the jackd output once started Matt … On 27/3/19 5:11 pm, fotisdr wrote: It works with plughw (it worked before the tweak as well) but the sound quality is terrible. On Tuesday, March 26, 2019, Matt Flax @.***> wrote: > What happens when you use plughw as the device ? > > On 26/3/19 7:45 pm, fotisdr wrote: >> >> http://forum.audioinjector.net/viewtopic.php?f=5&t=5687&p=8466 >> It's been 4 months now and I'm still struggling to find a solution, >> please help! >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub >> < #21 (comment) >, >> or mute the thread >> < https://github.com/notifications/unsubscribe-auth/AAq6B0hg1wYxZpRbYTdIbkkoVj6gnWM9ks5vad42gaJpZM4Y3ler >. >> > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread.< https://ci6.googleusercontent.com/proxy/RqOoy6Lv-J-lvMHybyKA43fkElROwwqgttSUSHtVArO4VlP8ryZcTeJFczOQ9E_mLo8j40NeWVD-gJfIVFs0at6gwcJu3c7AlFOty0ulHG56QFhGGvy0l79bdR5LNhvLnTIO7tnPggmP-7PBWgd5kpT93w=s0-d-e1-ft#https://github.com/notifications/beacon/AppcV4ykELkIronVpJodVb1bSWkf7y8Uks5vaoihgaJpZM4Y3ler.gif> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B5N0OcbSK50hhMVzYwcLVpSDBFoVks5vawubgaJpZM4Y3ler.

I have provided the jackd command previously in this issue: jackd --realtime -d alsa -d hw:audioinjectorpi,0 -p 1024 -r 16000 -n 2 And also the output:

ALSA: cannot set hardware parameters for capture
ALSA: cannot configure capture channel
Cannot initialize driver
JackServer: :Open failed with -1
Failed to open server

If I run the command with plughw or if I tweak the kernel as suggested in the forum the jackd server starts successfully with this command but the sound is terrible.

[fotisdr]

Actually, I tried today to use plughw after tweaking the kernel and it works! The jackd command is the same (with plughw instead of hw) and now I get proper audio with 16 kHz sampling rate :) What's the disadvantage of using plughw instead of hw? Does it increase computational load?

[flatmax]

There is more computational load because of the interpolation filter. It calculates how to reasmple the signal to get the correct sample rate - I seem to remember that you can alter the quality if CPU load is too much.

Also there is possibly a latency cost where before your algorithms get the audio, they have been buffered in the resampling algorithm - however I can't be too sure about this.

On 29/3/19 7:22 pm, fotisdr wrote:

Actually, I tried today to use plughw after tweaking the kernel and it works! The jackd command is the same (with plughw instead of hw) and now I get proper audio with 16 kHz sampling rate :) What's the disadvantage of using plughw instead of hw? Does it increase computational load?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477910602, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler.

[fotisdr]

There is more computational load because of the interpolation filter. It calculates how to reasmple the signal to get the correct sample rate - I seem to remember that you can alter the quality if CPU load is too much. Also there is possibly a latency cost where before your algorithms get the audio, they have been buffered in the resampling algorithm - however I can't be too sure about this. … On 29/3/19 7:22 pm, fotisdr wrote: Actually, I tried today to use plughw after tweaking the kernel and it works! The jackd command is the same (with plughw instead of hw) and now I get proper audio with 16 kHz sampling rate :) What's the disadvantage of using plughw instead of hw? Does it increase computational load? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler.

So there is no way to get native 16 kHz sampling rate? Because I have used a Cirrus audio card and it works without any tweaks or issues with native 16 kHz sampling rate.

[flatmax]

Yes there is a way.

You see in Nov. 2018 commits were made to enable multiple Pis to be plugged into one I2S bus and each Pi can act as a separate TDM time slot. Unfortunately these patches broke functionality for this type of card. Look here at the commits in November 2018 :

https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c

A significant question is; Are there more people who want better utility of their sound cards or are there more people who want to use many Pis on one I2S TDM bus ?

As far as native sample rates @ 8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to remove those patches.

Another option is to create a new bcm2835-silicon.c driver which implements the functionality of the bcm2835 silicon more robustly then the restricted i2s driver. In fact in the ALSA community, there is VERY VERY little acceptance for anything which matches the silicon rather then the i2s specification in an "i2s" driver. Which is reasonable from a high level conceptual stand point - however the silicon and hardware is always far more flexible then high level concepts - which quite frankly can be very limiting to a person's creativity.

On 29/3/19 7:47 pm, fotisdr wrote:

There is more computational load because of the interpolation
filter. It calculates how to reasmple the signal to get the
correct sample rate - I seem to remember that you can alter the
quality if CPU load is too much. Also there is possibly a latency
cost where before your algorithms get the audio, they have been
buffered in the resampling algorithm - however I can't be too sure
about this.
… <#>
On 29/3/19 7:22 pm, fotisdr wrote: Actually, I tried today to use
plughw after tweaking the kernel and it works! The jackd command
is the same (with plughw instead of hw) and now I get proper audio
with 16 kHz sampling rate :) What's the disadvantage of using
plughw instead of hw? Does it increase computational load? — You
are receiving this because you commented. Reply to this email
directly, view it on GitHub <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477910602>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler.

So there is no way to get native 16 kHz sampling rate? Because I have used a Cirrus audio card and it works without any tweaks or issues with native 16 kHz sampling rate.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477917735, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler.

[fotisdr]

Yes there is a way. You see in Nov. 2018 commits were made to enable multiple Pis to be plugged into one I2S bus and each Pi can act as a separate TDM time slot. Unfortunately these patches broke functionality for this type of card. Look here at the commits in November 2018 : https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c A significant question is; Are there more people who want better utility of their sound cards or are there more people who want to use many Pis on one I2S TDM bus ? As far as native sample rates @ 8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to remove those patches. Another option is to create a new bcm2835-silicon.c driver which implements the functionality of the bcm2835 silicon more robustly then the restricted i2s driver. In fact in the ALSA community, there is VERY VERY little acceptance for anything which matches the silicon rather then the i2s specification in an "i2s" driver. Which is reasonable from a high level conceptual stand point - however the silicon and hardware is always far more flexible then high level concepts - which quite frankly can be very limiting to a person's creativity. … On 29/3/19 7:47 pm, fotisdr wrote: There is more computational load because of the interpolation filter. It calculates how to reasmple the signal to get the correct sample rate - I seem to remember that you can alter the quality if CPU load is too much. Also there is possibly a latency cost where before your algorithms get the audio, they have been buffered in the resampling algorithm - however I can't be too sure about this. … <#> On 29/3/19 7:22 pm, fotisdr wrote: Actually, I tried today to use plughw after tweaking the kernel and it works! The jackd command is the same (with plughw instead of hw) and now I get proper audio with 16 kHz sampling rate :) What's the disadvantage of using plughw instead of hw? Does it increase computational load? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment) <#21 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler. So there is no way to get native 16 kHz sampling rate? Because I have used a Cirrus audio card and it works without any tweaks or issues with native 16 kHz sampling rate. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler.

So, I tried to revert the bcm2835-i2s.c file from the following commit, compile it and then copy it to the raspberry pi kernel (I suppose you meant Nov 2017 instead of 2018): https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7 However, after doing this, the soundcard doesn't work (it's not shown up in the aplay -l list). Is there a better way to do this?

[flatmax]

This is a little out of date, but shows the approach :

http://forum.audioinjector.net/viewtopic.php?f=10&t=3099

On 1/4/19 10:33 pm, fotisdr wrote:

Yes there is a way. You see in Nov. 2018 commits were made to
enable multiple Pis to be plugged into one I2S bus and each Pi can
act as a separate TDM time slot. Unfortunately these patches broke
functionality for this type of card. Look here at the commits in
November 2018 :
https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c
A significant question is; Are there more people who want better
utility of their sound cards or are there more people who want to
use many Pis on one I2S TDM bus ? As far as native sample rates @
8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to
remove those patches. Another option is to create a new
bcm2835-silicon.c driver which implements the functionality of the
bcm2835 silicon more robustly then the restricted i2s driver. In
fact in the ALSA community, there is VERY VERY little acceptance
for anything which matches the silicon rather then the i2s
specification in an "i2s" driver. Which is reasonable from a high
level conceptual stand point - however the silicon and hardware is
always far more flexible then high level concepts - which quite
frankly can be very limiting to a person's creativity.
… <#>
On 29/3/19 7:47 pm, fotisdr wrote: There is more computational
load because of the interpolation filter. It calculates how to
reasmple the signal to get the correct sample rate - I seem to
remember that you can alter the quality if CPU load is too much.
Also there is possibly a latency cost where before your algorithms
get the audio, they have been buffered in the resampling algorithm
- however I can't be too sure about this. … <#> On 29/3/19 7:22
pm, fotisdr wrote: Actually, I tried today to use plughw after
tweaking the kernel and it works! The jackd command is the same
(with plughw instead of hw) and now I get proper audio with 16 kHz
sampling rate :) What's the disadvantage of using plughw instead
of hw? Does it increase computational load? — You are receiving
this because you commented. Reply to this email directly, view it
on GitHub <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>
(comment) <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477910602>>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler.
So there is no way to get native 16 kHz sampling rate? Because I
have used a Cirrus audio card and it works without any tweaks or
issues with native 16 kHz sampling rate. — You are receiving this
because you commented. Reply to this email directly, view it on
GitHub <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477917735>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler.

So, I tried to revert the bcm2835-i2s.c file from the following commit, compile it and then copy it to the raspberry pi kernel (I suppose you meant Nov 2017 instead of 2018): raspberrypi/linux@beff053#diff-fc369f4a9c3260480afcc1d4cf211cd7 https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7 However, after doing this, the soundcard doesn't work (it's not shown up in the |aplay -l| list). Is there a better way to do this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-478543054, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6BxhHvPx7zaEEehFsIyhLKZ3Hg_zuks5vce6kgaJpZM4Y3ler.

[fotisdr]

This is a little out of date, but shows the approach : http://forum.audioinjector.net/viewtopic.php?f=10&t=3099 … On 1/4/19 10:33 pm, fotisdr wrote: Yes there is a way. You see in Nov. 2018 commits were made to enable multiple Pis to be plugged into one I2S bus and each Pi can act as a separate TDM time slot. Unfortunately these patches broke functionality for this type of card. Look here at the commits in November 2018 : https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c A significant question is; Are there more people who want better utility of their sound cards or are there more people who want to use many Pis on one I2S TDM bus ? As far as native sample rates @ 8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to remove those patches. Another option is to create a new bcm2835-silicon.c driver which implements the functionality of the bcm2835 silicon more robustly then the restricted i2s driver. In fact in the ALSA community, there is VERY VERY little acceptance for anything which matches the silicon rather then the i2s specification in an "i2s" driver. Which is reasonable from a high level conceptual stand point - however the silicon and hardware is always far more flexible then high level concepts - which quite frankly can be very limiting to a person's creativity. … <#> On 29/3/19 7:47 pm, fotisdr wrote: There is more computational load because of the interpolation filter. It calculates how to reasmple the signal to get the correct sample rate - I seem to remember that you can alter the quality if CPU load is too much. Also there is possibly a latency cost where before your algorithms get the audio, they have been buffered in the resampling algorithm - however I can't be too sure about this. … <#> On 29/3/19 7:22 pm, fotisdr wrote: Actually, I tried today to use plughw after tweaking the kernel and it works! The jackd command is the same (with plughw instead of hw) and now I get proper audio with 16 kHz sampling rate :) What's the disadvantage of using plughw instead of hw? Does it increase computational load? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 <#21> (comment) <#21 (comment) <#21 (comment)>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler. So there is no way to get native 16 kHz sampling rate? Because I have used a Cirrus audio card and it works without any tweaks or issues with native 16 kHz sampling rate. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment) <#21 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler. So, I tried to revert the bcm2835-i2s.c file from the following commit, compile it and then copy it to the raspberry pi kernel (I suppose you meant Nov 2017 instead of 2018): @.***#diff-fc369f4a9c3260480afcc1d4cf211cd7 [raspberrypi/linux@beff053#diff-fc369f4a9c3260480afcc1d4cf211cd7](https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7) However, after doing this, the soundcard doesn't work (it's not shown up in the |aplay -l| list). Is there a better way to do this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6BxhHvPx7zaEEehFsIyhLKZ3Hg_zuks5vce6kgaJpZM4Y3ler.

That's what I did but it didn't work with the Nov 2017 file. More specifically, I have a 4.14.98 version kernel so I reverted this file: https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7 Jackd starts with 16kHz now but the audio input is still not correct (it doesn't sound right or at least like the 32kHz input sounds - also it connects only mono). Do I need to change something more?

[flatmax]

On 2/4/19 5:43 pm, fotisdr wrote:

This is a little out of date, but shows the approach :
http://forum.audioinjector.net/viewtopic.php?f=10&t=3099
… <#>
On 1/4/19 10:33 pm, fotisdr wrote: Yes there is a way. You see in
Nov. 2018 commits were made to enable multiple Pis to be plugged
into one I2S bus and each Pi can act as a separate TDM time slot.
Unfortunately these patches broke functionality for this type of
card. Look here at the commits in November 2018 :
https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c
A significant question is; Are there more people who want better
utility of their sound cards or are there more people who want to
use many Pis on one I2S TDM bus ? As far as native sample rates @
8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to
remove those patches. Another option is to create a new
bcm2835-silicon.c driver which implements the functionality of the
bcm2835 silicon more robustly then the restricted i2s driver. In
fact in the ALSA community, there is VERY VERY little acceptance
for anything which matches the silicon rather then the i2s
specification in an "i2s" driver. Which is reasonable from a high
level conceptual stand point - however the silicon and hardware is
always far more flexible then high level concepts - which quite
frankly can be very limiting to a person's creativity. … <#> On
29/3/19 7:47 pm, fotisdr wrote: There is more computational load
because of the interpolation filter. It calculates how to reasmple
the signal to get the correct sample rate - I seem to remember
that you can alter the quality if CPU load is too much. Also there
is possibly a latency cost where before your algorithms get the
audio, they have been buffered in the resampling algorithm -
however I can't be too sure about this. … <#> On 29/3/19 7:22 pm,
fotisdr wrote: Actually, I tried today to use plughw after
tweaking the kernel and it works! The jackd command is the same
(with plughw instead of hw) and now I get proper audio with 16 kHz
sampling rate :) What's the disadvantage of using plughw instead
of hw? Does it increase computational load? — You are receiving
this because you commented. Reply to this email directly, view it
on GitHub <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21> <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>>
(comment) <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>
(comment) <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477910602>>>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler.
So there is no way to get native 16 kHz sampling rate? Because I
have used a Cirrus audio card and it works without any tweaks or
issues with native 16 kHz sampling rate. — You are receiving this
because you commented. Reply to this email directly, view it on
GitHub <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>
(comment) <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477917735>>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler.
So, I tried to revert the bcm2835-i2s.c file from the following
commit, compile it and then copy it to the raspberry pi kernel (I
suppose you meant Nov 2017 instead of 2018):
***@***.***#diff-fc369f4a9c3260480afcc1d4cf211cd7
<raspberrypi/linux@beff053#diff-fc369f4a9c3260480afcc1d4cf211cd7
<https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7>>
However, after doing this, the soundcard doesn't work (it's not
shown up in the |aplay -l| list). Is there a better way to do
this? — You are receiving this because you commented. Reply to
this email directly, view it on GitHub <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-478543054>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6BxhHvPx7zaEEehFsIyhLKZ3Hg_zuks5vce6kgaJpZM4Y3ler.

That's what I did but it didn't work with the Nov 2017 file.

OK - It needs someone to update it to make work with the current Raspbian.

did you work out which commit to use and roll back to ?

[fotisdr]

On 2/4/19 5:43 pm, fotisdr wrote: This is a little out of date, but shows the approach : http://forum.audioinjector.net/viewtopic.php?f=10&t=3099 … <#> On 1/4/19 10:33 pm, fotisdr wrote: Yes there is a way. You see in Nov. 2018 commits were made to enable multiple Pis to be plugged into one I2S bus and each Pi can act as a separate TDM time slot. Unfortunately these patches broke functionality for this type of card. Look here at the commits in November 2018 : https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c A significant question is; Are there more people who want better utility of their sound cards or are there more people who want to use many Pis on one I2S TDM bus ? As far as native sample rates @ 8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to remove those patches. Another option is to create a new bcm2835-silicon.c driver which implements the functionality of the bcm2835 silicon more robustly then the restricted i2s driver. In fact in the ALSA community, there is VERY VERY little acceptance for anything which matches the silicon rather then the i2s specification in an "i2s" driver. Which is reasonable from a high level conceptual stand point - however the silicon and hardware is always far more flexible then high level concepts - which quite frankly can be very limiting to a person's creativity. … <#> On 29/3/19 7:47 pm, fotisdr wrote: There is more computational load because of the interpolation filter. It calculates how to reasmple the signal to get the correct sample rate - I seem to remember that you can alter the quality if CPU load is too much. Also there is possibly a latency cost where before your algorithms get the audio, they have been buffered in the resampling algorithm - however I can't be too sure about this. … <#> On 29/3/19 7:22 pm, fotisdr wrote: Actually, I tried today to use plughw after tweaking the kernel and it works! The jackd command is the same (with plughw instead of hw) and now I get proper audio with 16 kHz sampling rate :) What's the disadvantage of using plughw instead of hw? Does it increase computational load? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 <#21> <#21 <#21>> (comment) <#21 <#21> (comment) <#21 (comment) <#21 (comment)>>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler. So there is no way to get native 16 kHz sampling rate? Because I have used a Cirrus audio card and it works without any tweaks or issues with native 16 kHz sampling rate. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 <#21> (comment) <#21 (comment) <#21 (comment)>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler. So, I tried to revert the bcm2835-i2s.c file from the following commit, compile it and then copy it to the raspberry pi kernel (I suppose you meant Nov 2017 instead of 2018): @.#diff-fc369f4a9c3260480afcc1d4cf211cd7 @.#diff-fc369f4a9c3260480afcc1d4cf211cd7 [raspberrypi/linux@beff053#diff-fc369f4a9c3260480afcc1d4cf211cd7](https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7)> However, after doing this, the soundcard doesn't work (it's not shown up in the |aplay -l| list). Is there a better way to do this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment) <#21 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6BxhHvPx7zaEEehFsIyhLKZ3Hg_zuks5vce6kgaJpZM4Y3ler. That's what I did but it didn't work with the Nov 2017 file. OK - It needs someone to update it to make work with the current Raspbian. did you work out which commit to use and roll back to ?

As I mentioned above:

That's what I did but it didn't work with the Nov 2017 file. More specifically, I have a 4.14.98 version kernel so I reverted this file: raspberrypi/linux@beff053#diff-fc369f4a9c3260480afcc1d4cf211cd7 Jackd starts with 16kHz now but the audio input is still not correct (it doesn't sound right or at least like the 32kHz input sounds - also it connects only mono). Do I need to change something more?

[flatmax]

On 3/4/19 6:36 pm, fotisdr wrote:

On 2/4/19 5:43 pm, fotisdr wrote: This is a little out of date,
but shows the approach :
http://forum.audioinjector.net/viewtopic.php?f=10&t=3099 … <#> On
1/4/19 10:33 pm, fotisdr wrote: Yes there is a way. You see in
Nov. 2018 commits were made to enable multiple Pis to be plugged
into one I2S bus and each Pi can act as a separate TDM time slot.
Unfortunately these patches broke functionality for this type of
card. Look here at the commits in November 2018 :
https://github.com/raspberrypi/linux/commits/rpi-4.19.y/sound/soc/bcm/bcm2835-i2s.c
A significant question is; Are there more people who want better
utility of their sound cards or are there more people who want to
use many Pis on one I2S TDM bus ? As far as native sample rates @
8kHz and 16 kHz, you need to revert the bcm2835-i2s.c driver to
remove those patches. Another option is to create a new
bcm2835-silicon.c driver which implements the functionality of the
bcm2835 silicon more robustly then the restricted i2s driver. In
fact in the ALSA community, there is VERY VERY little acceptance
for anything which matches the silicon rather then the i2s
specification in an "i2s" driver. Which is reasonable from a high
level conceptual stand point - however the silicon and hardware is
always far more flexible then high level concepts - which quite
frankly can be very limiting to a person's creativity. … <#> On
29/3/19 7:47 pm, fotisdr wrote: There is more computational load
because of the interpolation filter. It calculates how to reasmple
the signal to get the correct sample rate - I seem to remember
that you can alter the quality if CPU load is too much. Also there
is possibly a latency cost where before your algorithms get the
audio, they have been buffered in the resampling algorithm -
however I can't be too sure about this. … <#> On 29/3/19 7:22 pm,
fotisdr wrote: Actually, I tried today to use plughw after
tweaking the kernel and it works! The jackd command is the same
(with plughw instead of hw) and now I get proper audio with 16 kHz
sampling rate :) What's the disadvantage of using plughw instead
of hw? Does it increase computational load? — You are receiving
this because you commented. Reply to this email directly, view it
on GitHub <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21> <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>>
<#21 <https://github.com/Audio-Injector/stereo-and-zero/issues/21>
<#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>>>
(comment) <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21> <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>>
(comment) <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>
(comment) <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477910602>>>>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B3jzmHs_DLKg-Ft1mb7RVlFjwN0fks5vbc02gaJpZM4Y3ler.
So there is no way to get native 16 kHz sampling rate? Because I
have used a Cirrus audio card and it works without any tweaks or
issues with native 16 kHz sampling rate. — You are receiving this
because you commented. Reply to this email directly, view it on
GitHub <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21> <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>>
(comment) <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>
(comment) <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-477917735>>>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6B28qEIpRT6uD5R3vrOhAY_pYg-ylks5vbdM8gaJpZM4Y3ler.
So, I tried to revert the bcm2835-i2s.c file from the following
commit, compile it and then copy it to the raspberry pi kernel (I
suppose you meant Nov 2017 instead of 2018):
***@***.***#diff-fc369f4a9c3260480afcc1d4cf211cd7
***@***.***#diff-fc369f4a9c3260480afcc1d4cf211cd7
<raspberrypi/linux@beff053#diff-fc369f4a9c3260480afcc1d4cf211cd7
<https://github.com/raspberrypi/linux/commit/beff053c0ef6983897e3481169292e6435ef0a2d#diff-fc369f4a9c3260480afcc1d4cf211cd7>>>
However, after doing this, the soundcard doesn't work (it's not
shown up in the |aplay -l| list). Is there a better way to do
this? — You are receiving this because you commented. Reply to
this email directly, view it on GitHub <#21
<https://github.com/Audio-Injector/stereo-and-zero/issues/21>
(comment) <#21 (comment)
<https://github.com/Audio-Injector/stereo-and-zero/issues/21#issuecomment-478543054>>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq6BxhHvPx7zaEEehFsIyhLKZ3Hg_zuks5vce6kgaJpZM4Y3ler.
That's what I did but it didn't work with the Nov 2017 file.
OK - It needs someone to update it to make work with the current
Raspbian. did you work out which commit to use and roll back to ?

As I mentioned above:

That's what I did but it didn't work with the Nov 2017 file.
More specifically, I have a 4.14.98 version kernel so I reverted
this file:
raspberrypi/linux@beff053
<https://github.com/raspberrypi/linux/commit/beff053>#diff-fc369f4a9c3260480afcc1d4cf211cd7
Jackd starts with 16kHz now but the audio input is still not
correct (it doesn't sound right or at least like the 32kHz input
sounds - also it connects only mono). Do I need to change
something more?

if you cat the hw_params of the sound card whilst recording, what do you get ?

The command you need is something similar to this (during recording) :

cat /proc/asound/card0/pcm0c/sub0/hw_params

[fotisdr]

if you cat the hw_params of the sound card whilst recording, what do you get ? The command you need is something similar to this (during recording) : cat /proc/asound/card0/pcm0c/sub0/hw_params

So, below you can see different commands for jackd and the respective output of the cat /proc/asound/card0/pcm0c/sub0/hw_params:

jackd --realtime -d alsa -d hw:0,0 -p 1024 -r 32000 -n 2 -s 2 cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 32000 (32000/1) period_size: 1024 buffer_size: 2048

jackd --realtime -d alsa -d plughw:0,0 -p 1024 -r 16000 -n 2 -s 2 cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 32000 (32000/1) period_size: 2048 buffer_size: 4096

jackd --realtime -d alsa -d hw:0,0 -p 1024 -r 16000 -n 2 -s 2 cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 8000 (8000/1) period_size: 1024 buffer_size: 2048

As you can see, when I use hw and 16kHz the rate in the hw_params is 8000. I don't know the reason for this but even if I use hw and 8kHz I still get the same weird output (the cat /proc/asound/card0/pcm0c/sub0/hw_params gives the same output as in the last case). Any ideas?

[flatmax]

On 4/4/19 6:13 pm, fotisdr wrote:

if you cat the hw_params of the sound card whilst recording, what
do you get ? The command you need is something similar to this
(during recording) : cat /proc/asound/card0/pcm0c/sub0/hw_params

So, below you can see different commands for jackd and the respective output of the cat /proc/asound/card0/pcm0c/sub0/hw_params:

|jackd --realtime -d alsa -d hw:0,0 -p 1024 -r 32000 -n 2 -s 2 cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 32000 (32000/1) period_size: 1024 buffer_size: 2048 |

|jackd --realtime -d alsa -d plughw:0,0 -p 1024 -r 16000 -n 2 -s 2 cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 32000 (32000/1) period_size: 2048 buffer_size: 4096 |

|jackd --realtime -d alsa -d hw:0,0 -p 1024 -r 16000 -n 2 -s 2 cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 8000 (8000/1) period_size: 1024 buffer_size: 2048 |

As you can see, when I use hw and 16kHz the rate in the hw_params is

8000. I don't know the reason for this but even if I use hw and 8kHz I still get the same weird output (the |cat /proc/asound/card0/pcm0c/sub0/hw_params| gives the same output as in the last case). Any ideas?

I think at 8 kHz the stream is mono - or more likely one channel in both L&R capture streams. This is because of the in ability of the Pi set a high enough number in its hardware register to capture the second channel from the bit stream in silicon.

[fotisdr]

I think at 8 kHz the stream is mono - or more likely one channel in both L&R capture streams. This is because of the in ability of the Pi set a high enough number in its hardware register to capture the second channel from the bit stream in silicon.

But I don't care for 8 kHz (only for 16 kHz) or if the sound is mono. What I want is to get the correct audio input with 16kHz (as in 32 kHz) without downsampling. If the problem is the revision of the bcm2835-i2s file, I think I have tried everything to make the 16kHz sampling rate to work and nothing seems to be working. Is there a way to do this with the audioinjector sound card or should I buy an RPI cirrus one?