Trying the new stuff in 0.11.0

[Stifu]

It's already been renamed to getActiveEffects.

Nice, thanks for the info!

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]

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.

[josip]

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]

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

[josip]

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]

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]

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.

[jack0088]

@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]

@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.

[jack0088]

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

#Edit. Thank you found everything.