## Trying the new stuff in 0.11.0

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Stifu
Prole
Posts: 23
Joined: Mon Mar 14, 2016 9:53 am
Contact:

### Re: Trying the new stuff in 0.11.0

slime wrote:
Mon Aug 07, 2017 9:56 pm
It's already been renamed to getActiveEffects.
Nice, thanks for the info!
raidho36 wrote:
Tue Aug 08, 2017 6:44 am
As for naming - it's already been highlighted that there isn't a whole lot of consistency either way so yeah.
Well, even though the API naming may not be very consistent now, it's still worth making an effort to avoid making things any worse... unless LÖVE is really trying to compete with PHP when it comes to API inconsistencies. :p

Santos
Party member
Posts: 375
Joined: Sat Oct 22, 2011 7:37 am

### Re: Trying the new stuff in 0.11.0

Here is another sound recording example, showcasing what is clearly the ultimate use case.

Speak, whistle, scream, hum, or curse into the microphone at the same time as you press any key. This can be repeated.
Attachments
recording.love

josip
Prole
Posts: 8
Joined: Tue Oct 03, 2017 1:55 pm

### Re: Trying the new stuff in 0.11.0

Did anyone try building v0.11 for Android?

I got it working by dropping 'minor' branch into love-android-sdl2 source and adding bunch of new source paths into Android.mk. I did not update OpenAL-Soft, so it's still at version 1.17.0. The most stuff I tried is working great - touch input, graphics, playing sounds, adding sound effects...

Unfortunately, recording sound does not work. The function love.audio.getRecordingDevices() returns single device. When I call getData() on that device object, I get false return value.

The adb logcat shows these lines:

Code: Select all

10-09 18:08:26.506   632   632 D audio_hw_primary: adev_open_input_stream: enter: sample_rate(16000) channel_mask(0x10) devices(0x80000004)        stream_handle(0xabb13990) io_handle(8721) source(6)
10-09 18:08:26.507   632 16737 I AudioFlinger: AudioFlinger's thread 0xabc8aa58 ready to run
10-09 18:08:26.507   632 16737 D audio_hw_primary: in_standby: enter: stream (0xabb13990) usecase(16: audio-record)
10-09 18:08:26.509   632 16737 D audio_hw_primary: in_standby: enter: stream (0xabb13990) usecase(16: audio-record)
10-09 18:08:26.512   632  1574 V AudioPolicyManagerCustom: startInput() input 8721
10-09 18:08:26.512   632  1574 E AudioPolicyManagerCustom: startInput(8721) failed: other input 8251 already started
10-09 18:08:26.513 30668 31699 E AudioRecord: start() status -38
10-09 18:08:26.513 30668 31699 E AudioProvider: recording stopped, not in RECORDSTATE_RECORDING state
10-09 18:08:26.516 30668 31699 I GsaVoiceInteractionSrv: #onClosed - Hotword is not running
10-09 18:08:26.518   632 15771 D audio_hw_primary: adev_close_input_stream: enter:stream_handle(0xabb13990)
10-09 18:08:26.518   632 15771 D audio_hw_primary: in_standby: enter: stream (0xabb13990) usecase(16: audio-record)

It would seem that recording was started twice for some reason and it naturally fails on the second attempt. Anyone has an idea what could cause it?

slime
Solid Snayke
Posts: 2716
Joined: Mon Aug 23, 2010 6:45 am
Contact:

### Re: Trying the new stuff in 0.11.0

I believe OpenAL Soft 1.18 added audio recording support on Android.

josip
Prole
Posts: 8
Joined: Tue Oct 03, 2017 1:55 pm

### Re: Trying the new stuff in 0.11.0

Oh, that's good to know, thanks! I actually found it changelog once you pointed that out.

I'm still struggling with building the Android project with new openal version, mostly because the Gradle stuff is something I never did before. Now the project is breaking apart so much that even the clean operation breaks with errors

jack0088
Prole
Posts: 32
Joined: Fri Mar 22, 2013 4:59 am

### Re: Trying the new stuff in 0.11.0

Does anyone have an idea how I can record for "unlimited" time?

My recorder has a buffer of 3 seconds, calculated from sample rate it is:

Code: Select all

sampleRate * 3
Then I made a queueable source and after each second of recording I push the recoded buffer into the queueable source..

Code: Select all

recorder:getSampleCount() > recorder:getSampleRate()
I also think that when getting the data from the recorder it actually clears it and starts over. So theoretically my buffer gets never completely filled before I fetch it and queue its contents. So all fine here.

But still, my recording is not longer than couple of seconds. Why that?

Here's my code:

Code: Select all

function love.load()
deviceList = love.audio.getRecordingDevices()
sampleRate = 44100 -- quality in number of samples per second
bitDepth = 16 -- resolution
numChannels = 1
bufferTime = 3 -- in seconds
numSamples = sampleRate * bufferTime -- recording buffer length

recorder = deviceList[1]

tape = love.audio.newQueueableSource(sampleRate, bitDepth, numChannels)
end

function love.draw()
if tape and recorder then
if recorder:isRecording() and recorder:getSampleCount() > recorder:getSampleRate() then -- each second of recording time
tape:queue(recorder:getData()) -- queue the recorded snippet
end
end

love.graphics.print('sampleCount: '..recorder:getSampleCount())
end

function love.keyreleased(key)
-- press p to start recording. hit p again to stop recording and play the recorded snippet. repeat again if you want.

if key == "p" then
if recorder:isRecording() then
recorder:stop()
print("pause recording")
else
recorder:start(numSamples, sampleRate, bitDepth, numChannels)
print("resume recording")
end

if not recorder:isRecording() and not tape:isPlaying() then
tape:play()
print("play queue")
end
end
end
PS: Another thing I noticed is that I can not rewind a queueable source like "tape:rewind()" is that true?

zorg
Party member
Posts: 1914
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: Trying the new stuff in 0.11.0

jack0088 wrote:
Sat Nov 11, 2017 6:56 pm
Does anyone have an idea how I can record for "unlimited" time?
...
You need to call :play on your QSource after you queued data onto it, if you want to play back the input continuously; if you want to keep that data around, then you'll either need more buffers, fill them one after another, and probably serialize the data out to file(s); in that case though, you don't need a QSource at all, only the Recording device.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

jack0088
Prole
Posts: 32
Joined: Fri Mar 22, 2013 4:59 am

### Re: Trying the new stuff in 0.11.0

@zorg I'm not sure I understand your response completely - so let's have an example:
My app has a button "record voice"
The user tap on it and can now speak for unlimited time!
When the user taps button "stop recording" the app should play the whole recoded snippet.

Issue: when start recording I have to give it a buffer size (first parameter "samples") but I do no know at this moment how long the user will be recording for.

> From what you're saying it looks like I should monitor the recorder:getSampleCount() and when its filled create another one. Is that correct?
> Lets say the user spoke for 1 minute and stopped. Based on this I would breal the recording into 4 independent buffers (each 15 seconds @44kHz = 661500 samples). Now I could use the QSource to play back all of them, right? Is the QSource something like a playlist? I thought it would be a buffer of flexible length which you can rewind, play, stop, or seek..

zorg
Party member
Posts: 1914
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: Trying the new stuff in 0.11.0

jack0088 wrote:
Sat Nov 11, 2017 7:17 pm
@zorg I'm not sure I understand your response completely - so let's have an example:
My app has a button "record voice"
The user tap on it and can now speak for unlimited time!
When the user taps button "stop recording" the app should play the whole recoded snippet.

Issue: when start recording I have to give it a buffer size (first parameter "samples") but I do no know at this moment how long the user will be recording for.

> From what you're saying it looks like I should monitor the recorder:getSampleCount() and when its filled create another one. Is that correct?
> Lets say the user spoke for 1 minute and stopped. Based on this I would breal the recording into 4 independent buffers (each 15 seconds @44kHz = 661500 samples). Now I could use the QSource to play back all of them, right? Is the QSource something like a playlist? I thought it would be a buffer of flexible length which you can rewind, play, stop, or seek..
Yeah, i didn't understand you completely myself, that's why i came up with answers to two different things; your follow-up cleared things up though!

So, technically, you will sooner or later find yourself hitting memory limitations, but for the time being, let's not care about that.

You only need to give a size parameter to SoundDatas (and recording devices), QSources don't require such a parameter.

Indeed, you should monitor if the recorded sample count is greater or equal to one (SoundData) buffer's length, which you defined; if it is, then you need to put the SoundData object you got with recorder:getData into a table; i am assuming that that creates new SoundData objects with time, so there shouldn't be an issue with all returned SD object being the same, and having your data overwritten.

QSources are indeed like playlists, except they behave like a queue; you push data onto them, and the data you pushed last will be played last, so it plays enqueued data sequentially.

You don't need to create buffers that long though, 15 seconds is a ton; 1 second buffers should suffice, i'd say.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

jack0088
Prole
Posts: 32
Joined: Fri Mar 22, 2013 4:59 am

### Re: Trying the new stuff in 0.11.0

@zorg uh wow, thank you for such detailed explanation!

#Edit. Thank you found everything.

### Who is online

Users browsing this forum: No registered users and 7 guests