`wavplay(y, fs)` does not work about wav.jl HOT 11 CLOSED

Turns out it is an issue with WAV v1.0.3. I solved it by removing the package and pulling the master:

] rm WAV
] add https://github.com/dancasimiro/WAV.jl

from wav.jl.

@dancasimiro In v1.0.3, Project.toml said

version = "1.0.3"

[compat]
FileIO = "≥ 0.2.0"
julia = "≥ 0.7.0"

but in the current main branch it says

version = "1.0.4"

[compat]
FileIO = "0.2, 1.4"
julia = "0.7, 1.5"

That has at least two problems:

• If you make any changes to the [compat] section, I believe you will also have to change to version = "1.1.0", as this no longer counts as a “patch” under semantic versioning.
• Did you really intend to say that Julia 1.0, 1.1, ..., 1.4, are not compatible?
• The FileIO compatibility requirements look similarly odd (i.e., explicitly incompatible with FileIO 0.3.x–1.3.x).

See: https://julialang.github.io/Pkg.jl/v1/compatibility/ and in particular Behavior of versions with leading zeros.

On reflection, I now believe the changes (e.g., wavplay() works again, the way the documentation is formatted) are significant enough to count as a minor release, not as a (third-level increment) “patch”, therefore I would suggest to move to

version = "1.1.0"

The compatible Julia versions should probably be specified as

julia = "0.7, 1"

In fact, it is probably time to drop 0.7, as that hasn't been officially supported for a long time, i.e.

julia = "1"

is also fine.

I don't know anything about the actual compatibility requirements of FileIO, but I suspect you also meant to say something like

FileIO = "0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1"

and perhaps

FileIO = "1"

is also fine now?

Or just keep

[compat]
FileIO = "≥ 0.2.0"
julia = "≥ 0.7.0"

as it was. (As long as there is no breaking Julia 2 or FileIO 2 on the horizon to worry about.)

from wav.jl.

@dancasimiro Any chance you could merge PR #93 to make JuliaRegistrator happier and then tag/release v1.1.0?

(My students have to do a signal-processing exercise in the coming weeks where Julia+WAV.jl is one of the recommended platforms. The current master fixes all the problems that my students encountered last year with wavplay and the documentation in that exercise, so it would be great to get it released asap.)

from wav.jl.

I'm having the same problem. It seems like the these lines under WAV.jl are not doing their job:

function wavplay end
wavplay(fname::AbstractString) = wavplay(wavread(fname)[1:2]...)
@static if Sys.islinux()
    include("wavplay-pulse.jl")
elseif Sys.isapple()
    include("wavplay-audioqueue.jl")
elseif Sys.iswindows()
    include("wavplay-win32.jl")
else
    wavplay(data, fs) = @warn "wavplay is not currently implemented on $(Sys.KERNEL)"
end

from wav.jl.

Thank you!

I look forward to the release of the new version. 1.0.4 😄

from wav.jl.

@dancasimiro Could you please tag the current main branch head as the v1.0.4 release? At the moment, the latest release tag is still v1.0.3, where wavplay() does not work at all on any currently supported Julia version.

from wav.jl.

@mgkuhn I have attempted to tag v1.0.4. You can follow the progress at JuliaRegistries/General#22393

from wav.jl.

@dancasimiro Is deploying CompatHelper actually useful here? The compatibility requirements of WAV.jl seem extremely simple currently, so I don't understand what problems CompatHelper would solve here (rather than create!).

from wav.jl.

PR #93 is how I would suggest to proceed.

from wav.jl.

Small note for future people: if you are using julia and WAV.jl within the windows subsystem for linux (WSL) then wavplay fails with the following error. This may have been fixed in WSL v2, but at least for v1 it's broken.

shared memfd open() failed: Function not implemented
pa_simple_new failed

error(::String)@error.jl:33
wavplay(::Array{Float64,2}, ::Float32)@wavplay-pulse.jl:118
wavplay(::String)@WAV.jl:1075
top-level scope@Local: 1

from wav.jl.

[That should have been a new issue really]

Are you running pulseaudio there? Do other Linux audio applications work? Via pulseaudio or via other audio APIs?

If not, I would not have expected WAV.wavplay to work.

I'm no expert on the state of audio device access on WSL and WSL2 in general. From a quick web search, I gather that neither WSL or WSL2 have any access to an audio device, but people have succeeded in running PulseAudio on both WSL and Windows simultaneously and then configuring them to pass over the sound from one to the other via TCP: https://www.reddit.com/r/bashonubuntuonwindows/comments/hrn1lz/wsl_sound_through_pulseaudio_solved/

Based on that, I don't see what better WAV.jl could do than to be a PulseAudio client, which it already is.

P.S.: WSL[2] will probably always remain a horrendous hack. For the best experience with hardware I/O, I recommend to get a proper operating system, not stacks of kernel emulation layers or VMs.

from wav.jl.