Audio from audio source to pipe (stdout/stdin)

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I am trying to get an audio stream from Bluetooth to the stdin of fm_transmitter on my Raspberry Pi 3 / up-to-date Raspbian Stretch.




So far, I got FM-Transmitter running with an ICE-Cast-Stream using ffmpeg & my Pi is playing Music from Spotify via bluetooth (I installed blueman next to the things I followed from this Tutorial).




To archive this, I tried using ffmpeg -f s16le -i hw:0 - | fm_transmitter -f 87.6 - as mentioned in tutorials, and tested with all the other devices listed with aplay -L. But it can not listen to any of the sources / can't find it.



So as main concern, I am wondering which tool can link an audio-source to the pipe.







share|improve this question






















  • There is no Bluetooth audio device in your list, and AFAIK ALSA doesn't deal with Bluetooth. Use Pulseaudio instead.
    – dirkt
    Nov 5 '17 at 7:26










  • @dirkt thanks for the hint! I was able to find the BT audio-source with pactl. I also updated my answer, according to the things I found out yet.
    – x.NET Development
    Nov 6 '17 at 23:20














up vote
1
down vote

favorite












I am trying to get an audio stream from Bluetooth to the stdin of fm_transmitter on my Raspberry Pi 3 / up-to-date Raspbian Stretch.




So far, I got FM-Transmitter running with an ICE-Cast-Stream using ffmpeg & my Pi is playing Music from Spotify via bluetooth (I installed blueman next to the things I followed from this Tutorial).




To archive this, I tried using ffmpeg -f s16le -i hw:0 - | fm_transmitter -f 87.6 - as mentioned in tutorials, and tested with all the other devices listed with aplay -L. But it can not listen to any of the sources / can't find it.



So as main concern, I am wondering which tool can link an audio-source to the pipe.







share|improve this question






















  • There is no Bluetooth audio device in your list, and AFAIK ALSA doesn't deal with Bluetooth. Use Pulseaudio instead.
    – dirkt
    Nov 5 '17 at 7:26










  • @dirkt thanks for the hint! I was able to find the BT audio-source with pactl. I also updated my answer, according to the things I found out yet.
    – x.NET Development
    Nov 6 '17 at 23:20












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I am trying to get an audio stream from Bluetooth to the stdin of fm_transmitter on my Raspberry Pi 3 / up-to-date Raspbian Stretch.




So far, I got FM-Transmitter running with an ICE-Cast-Stream using ffmpeg & my Pi is playing Music from Spotify via bluetooth (I installed blueman next to the things I followed from this Tutorial).




To archive this, I tried using ffmpeg -f s16le -i hw:0 - | fm_transmitter -f 87.6 - as mentioned in tutorials, and tested with all the other devices listed with aplay -L. But it can not listen to any of the sources / can't find it.



So as main concern, I am wondering which tool can link an audio-source to the pipe.







share|improve this question














I am trying to get an audio stream from Bluetooth to the stdin of fm_transmitter on my Raspberry Pi 3 / up-to-date Raspbian Stretch.




So far, I got FM-Transmitter running with an ICE-Cast-Stream using ffmpeg & my Pi is playing Music from Spotify via bluetooth (I installed blueman next to the things I followed from this Tutorial).




To archive this, I tried using ffmpeg -f s16le -i hw:0 - | fm_transmitter -f 87.6 - as mentioned in tutorials, and tested with all the other devices listed with aplay -L. But it can not listen to any of the sources / can't find it.



So as main concern, I am wondering which tool can link an audio-source to the pipe.









share|improve this question













share|improve this question




share|improve this question








edited Nov 8 '17 at 14:01

























asked Nov 5 '17 at 0:23









x.NET Development

165




165











  • There is no Bluetooth audio device in your list, and AFAIK ALSA doesn't deal with Bluetooth. Use Pulseaudio instead.
    – dirkt
    Nov 5 '17 at 7:26










  • @dirkt thanks for the hint! I was able to find the BT audio-source with pactl. I also updated my answer, according to the things I found out yet.
    – x.NET Development
    Nov 6 '17 at 23:20
















  • There is no Bluetooth audio device in your list, and AFAIK ALSA doesn't deal with Bluetooth. Use Pulseaudio instead.
    – dirkt
    Nov 5 '17 at 7:26










  • @dirkt thanks for the hint! I was able to find the BT audio-source with pactl. I also updated my answer, according to the things I found out yet.
    – x.NET Development
    Nov 6 '17 at 23:20















There is no Bluetooth audio device in your list, and AFAIK ALSA doesn't deal with Bluetooth. Use Pulseaudio instead.
– dirkt
Nov 5 '17 at 7:26




There is no Bluetooth audio device in your list, and AFAIK ALSA doesn't deal with Bluetooth. Use Pulseaudio instead.
– dirkt
Nov 5 '17 at 7:26












@dirkt thanks for the hint! I was able to find the BT audio-source with pactl. I also updated my answer, according to the things I found out yet.
– x.NET Development
Nov 6 '17 at 23:20




@dirkt thanks for the hint! I was able to find the BT audio-source with pactl. I also updated my answer, according to the things I found out yet.
– x.NET Development
Nov 6 '17 at 23:20










1 Answer
1






active

oldest

votes

















up vote
1
down vote













ffmpeg seems not to be able to do what I need and aplay -L wasn't capable of finding Bluetooth sources. But with pactl list sources short I finally found the A2DP-source.



Anyways, after messing around with sox, I finally got an audio signal from default-device to bash, but it was stuttering as I used the following command.



$ sox -d -t raw -r 22.05k -b 8 - gain -5 | fm_transmitter -f 87.6 -



After I thought of the sampling rate at first place being 44.8k, and the piped rate being 22.05k - which is not perfectly dividable - I tried different tempo rates.



I found tempo 0.97 being fine for me, still it stutters in the first seconds but then it works.



The only issue is, the tempo reduce adds a slight stacking delay - which isn't perfect nor real-time at all.



$ sox -d -t raw -b 8 -r 22050 - gain -5 tempo 0.97 | fm_transmitter -f 87.6 -

Playing: stdin, 22050 Hz, 16 bits, mono

Input File : 'default' (alsa)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:07:15.97 [00:00:00.00] Out:9.90M [ =====|===== ] Hd:4.4 Clip:0





share|improve this answer






















  • BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
    – dirkt
    Nov 7 '17 at 7:34










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f402570%2faudio-from-audio-source-to-pipe-stdout-stdin%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













ffmpeg seems not to be able to do what I need and aplay -L wasn't capable of finding Bluetooth sources. But with pactl list sources short I finally found the A2DP-source.



Anyways, after messing around with sox, I finally got an audio signal from default-device to bash, but it was stuttering as I used the following command.



$ sox -d -t raw -r 22.05k -b 8 - gain -5 | fm_transmitter -f 87.6 -



After I thought of the sampling rate at first place being 44.8k, and the piped rate being 22.05k - which is not perfectly dividable - I tried different tempo rates.



I found tempo 0.97 being fine for me, still it stutters in the first seconds but then it works.



The only issue is, the tempo reduce adds a slight stacking delay - which isn't perfect nor real-time at all.



$ sox -d -t raw -b 8 -r 22050 - gain -5 tempo 0.97 | fm_transmitter -f 87.6 -

Playing: stdin, 22050 Hz, 16 bits, mono

Input File : 'default' (alsa)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:07:15.97 [00:00:00.00] Out:9.90M [ =====|===== ] Hd:4.4 Clip:0





share|improve this answer






















  • BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
    – dirkt
    Nov 7 '17 at 7:34














up vote
1
down vote













ffmpeg seems not to be able to do what I need and aplay -L wasn't capable of finding Bluetooth sources. But with pactl list sources short I finally found the A2DP-source.



Anyways, after messing around with sox, I finally got an audio signal from default-device to bash, but it was stuttering as I used the following command.



$ sox -d -t raw -r 22.05k -b 8 - gain -5 | fm_transmitter -f 87.6 -



After I thought of the sampling rate at first place being 44.8k, and the piped rate being 22.05k - which is not perfectly dividable - I tried different tempo rates.



I found tempo 0.97 being fine for me, still it stutters in the first seconds but then it works.



The only issue is, the tempo reduce adds a slight stacking delay - which isn't perfect nor real-time at all.



$ sox -d -t raw -b 8 -r 22050 - gain -5 tempo 0.97 | fm_transmitter -f 87.6 -

Playing: stdin, 22050 Hz, 16 bits, mono

Input File : 'default' (alsa)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:07:15.97 [00:00:00.00] Out:9.90M [ =====|===== ] Hd:4.4 Clip:0





share|improve this answer






















  • BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
    – dirkt
    Nov 7 '17 at 7:34












up vote
1
down vote










up vote
1
down vote









ffmpeg seems not to be able to do what I need and aplay -L wasn't capable of finding Bluetooth sources. But with pactl list sources short I finally found the A2DP-source.



Anyways, after messing around with sox, I finally got an audio signal from default-device to bash, but it was stuttering as I used the following command.



$ sox -d -t raw -r 22.05k -b 8 - gain -5 | fm_transmitter -f 87.6 -



After I thought of the sampling rate at first place being 44.8k, and the piped rate being 22.05k - which is not perfectly dividable - I tried different tempo rates.



I found tempo 0.97 being fine for me, still it stutters in the first seconds but then it works.



The only issue is, the tempo reduce adds a slight stacking delay - which isn't perfect nor real-time at all.



$ sox -d -t raw -b 8 -r 22050 - gain -5 tempo 0.97 | fm_transmitter -f 87.6 -

Playing: stdin, 22050 Hz, 16 bits, mono

Input File : 'default' (alsa)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:07:15.97 [00:00:00.00] Out:9.90M [ =====|===== ] Hd:4.4 Clip:0





share|improve this answer














ffmpeg seems not to be able to do what I need and aplay -L wasn't capable of finding Bluetooth sources. But with pactl list sources short I finally found the A2DP-source.



Anyways, after messing around with sox, I finally got an audio signal from default-device to bash, but it was stuttering as I used the following command.



$ sox -d -t raw -r 22.05k -b 8 - gain -5 | fm_transmitter -f 87.6 -



After I thought of the sampling rate at first place being 44.8k, and the piped rate being 22.05k - which is not perfectly dividable - I tried different tempo rates.



I found tempo 0.97 being fine for me, still it stutters in the first seconds but then it works.



The only issue is, the tempo reduce adds a slight stacking delay - which isn't perfect nor real-time at all.



$ sox -d -t raw -b 8 -r 22050 - gain -5 tempo 0.97 | fm_transmitter -f 87.6 -

Playing: stdin, 22050 Hz, 16 bits, mono

Input File : 'default' (alsa)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:07:15.97 [00:00:00.00] Out:9.90M [ =====|===== ] Hd:4.4 Clip:0






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 8 '17 at 13:28

























answered Nov 7 '17 at 1:20









x.NET Development

165




165











  • BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
    – dirkt
    Nov 7 '17 at 7:34
















  • BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
    – dirkt
    Nov 7 '17 at 7:34















BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
– dirkt
Nov 7 '17 at 7:34




BTW, the direct equivalent of aplay is paplay, but of course sox also works. Getting audio sources and sinks with different clocks synchronized is a real PITA. Pulseaudio has integrated resampling, and I suppose if you adjust the rate directly instead of using tempo it might work better, but that will need experimentation.
– dirkt
Nov 7 '17 at 7:34

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f402570%2faudio-from-audio-source-to-pipe-stdout-stdin%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?